Open Bug 1338831 Opened 5 years ago Updated 11 days ago

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

Categories

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

defect
Not set
normal

Tracking

()

REOPENED
Tracking Status
firefox74 --- wontfix
firefox75 --- fix-optional
firefox76 --- fix-optional

People

(Reporter: aryx, Unassigned)

References

(Regression)

Details

(Keywords: regression, Whiteboard: e10s)

Attachments

(1 file, 1 obsolete file)

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.
Edge has the same problem (if this is a problem at all.) Maybe this is not important for the web compat.
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.
Flags: needinfo?(mconley)
Priority: -- → P5
(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.
Flags: needinfo?(mconley)
Component: DOM → DOM: Core & HTML

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.

Blocks: 1007344
No longer blocks: 1240085
Priority: P5 → --
Regressed by: 1240085

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

Flags: needinfo?(htsai)

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

(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.

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

Flags: needinfo?(htsai) → needinfo?(echen)
Attached file test.html (obsolete) —
Flags: needinfo?(echen)

(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.

Attachment #9138753 - Attachment is obsolete: true

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

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID

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.

Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.