The worst thing is that window.screenTop is also broken: after the window is unexpected moved down, it returns the same value as before, so you can't even detect that and compensate for it as a workaround.


BTW also tested on Beta, issue still there.

It is all SO screwed up.

1) If you do this:
  console.log(window.screenTop);
  window.moveBy(30,0); // or any non-zero value for x (or y, for that matter)
  console.log(window.screenTop);

=> the window moves down but the two logged values for screenTop are the same

This would seem to suggest that moveBy is broken and scrollTop is not immediately updated. However:

2) If you do this:
  console.log(window.screenTop);
  window.moveTo(300, 300);
  console.log(window.screenTop);

 RUN IT TWICE or several times, not consecutively

=> The first time, the window moves to something supposedly near 300,300. The second time, and any further time, the window remains where it is, but the output is always
  328
  300

Think about it: this already makes no sense.

3)
  console.log(window.screenTop);
  window.moveTo(window.screenLeft+30,window.screenTop);
  console.log(window.screenTop);

=> the window moves down but the two logged values are the same - i.e. the outcome is just the same as when using moveBy(30,0)


4) HOWEVER THIS:
  console.log(window.screenTop);
  window.moveTo(window.screenLeft,window.screenTop);
  console.log(window.screenTop);

=> the window doesn't move, AND the two logged values are the same (i.e. completely expected behavior, hurray!).

This is inconsistent with everything else.



My head explodes while trying to make sense of it.

The only explanation I can think of is that:
i - when the top position is *read* NOT right after setting a new position (i.e. it is actually "measured"), it is defined inconsistently with the way it is defined when a new position is applied
ii - however, when it is read right after setting it, it simply reads the value that was assigned, that is:
   moveTo(x,y);
   console.log(window.screenTop); // systematically returns y as a kind of shortcut
as opposed to measuring the position as it would if it hasn't just been set.


This still doesn't explain how window.moveTo(window.scrollLeft,window.scrollTop) behaves as expected, in that the window does not move AND the value of scrollTop before and after doesn't change. The only explanation is that:
iii - window.moveTo(window.scrollLeft,window.scrollTop) is treated like a special case, and does literally nothing

Which is just an extra layer of stupidity, probably meant to be "clever".

Navigated to the URL provided in issue and is able to reproducible the issue on Ubuntu 14.04 on Chrome Stable# 52.0.2743.116.
This is a Non-Regression issue seen from M32 builds. Below are the observations,

From M39 Builds# 39.0.2127.0 the issue is reproducible as mentioned in the issue.
Till M38 builds# 38.0.2125.0 the pop-up moves towards left but only once.

Changing the status to Untriaged so that the issue would get addressed.
Thank You.

> This is a Non-Regression issue seen from M32 builds.

Does that mean that you tested starting from that version?

I'm 100% POSITIVE that at some point this did work. It may have been years ago but it worked.

lfg: Are you familiar with moveBy() ?

I cannot reproduce this on Windows, is this Linux-specific?

I just confirmed that this bug is Linux-specific. I guess it's something to do with aura or linux window manager's implementation. sadrul@, any thoughts?