1338831 - [e10s] some attributes of opened windows not directly available wrong if directly fetched after using window.open

Status: REOPENED

(Core :: DOM: Core & HTML, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Firefox 54.0a1 64-bit on Windows 8.1 64-bit
screen resolution 1920x1080, Windows OS zoom 1.25 (device pixel ratio)
e10s must be enabled

var mywin = window.open("about:blank", "MyWindow", "left=300");
alert(mywin.screenX);

This yields 0 in e10s mode and the correct value (here 300) in non-e10s mode

Mozregression finds https://hg.mozilla.org/mozilla-central/rev/7d6e0141de4f as culprit with Gecko 47.0a1, but on release Firefox 48 is the first one failing here.

Adding a listener for DOMContentLoaded and then checking mywin.screenX works as expected.

Comment 1

[Masatoshi Kimura [:emk]]

Edge has the same problem (if this is a problem at all.) Maybe this is not important for the web compat.

Comment 2

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Triage meeting: this looks quite edgy, so we set a rather low priority.
Mike, we are still flagging you, as you might be interested in the difference b/w e10s and non-e10s.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #2)
> Triage meeting: this looks quite edgy, so we set a rather low priority.
> Mike, we are still flagging you, as you might be interested in the
> difference b/w e10s and non-e10s.

I agree, low priority.

Comment 4

[Matthew N. [:MattN]]

This is the underlying cause of bug 1007344 which caused XUL notifications to appear off-screen in many cases since it uses these screen* values before the load event. We have worked around it for now but it seems like we may want a proper fix in DOM code.

Comment 5

[Jens Stutte [:jstutte]]

Hi Hsin-Yi, can you please (let) triage this? Thank you!

Comment 6

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Interesting ... I got the expected result on Release 74 but got 0 on Nightly 76.

Comment 7

[Hsin-Yi Tsai (she/her)[:hsinyi]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #6)

Interesting ... I got the expected result on Release 74 but got 0 on Nightly 76.
Aha, not really expected result, it was always 115 on various release versions.

Comment 8

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Hi Edgar, could you help us understand how complicated the fix may be? Also wonder how the solution would be for Fission-compatible.

Comment 9

[Edgar Chen [:edgar]]

Attachment: test.html

Comment 10

[Edgar Chen [:edgar]]

Attachment: test_with_specifying_window_size.html

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #7)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #6)

Interesting ... I got the expected result on Release 74 but got 0 on Nightly 76.
Aha, not really expected result, it was always 115 on various release versions.

What I observe is that if we don't sepcify size for popup, it will use the same size as opener.
And if the popup could not be full visible on screen on specified position (left=300), then we will offset its position to make it could be full visible.

Update test with specifying the window size.

Comment 11

[Edgar Chen [:edgar]]

I think this issue is no longer valid,

• I could not reproduce the issue on Nightly 76, Release 74 and Release 57.
• but I could reproduce this on Rlease 54.

Here is the possible fixing,
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=035c25bef7b5e4175006e63eff10c61c2eef73f1&tochange=fe809f57bf2287bb937c3422ed03a63740b3448b

Comment 12

[Matthew N. [:MattN]]

The issue is still valid as we just put a workaround in bug 1007344 for alert service windows on Windows a few weeks ago. You can backout that patch to see the issue easily on Windows. See the STR in that bug.