[e10s] Popup Window - innerHeight and innerWidth return 0

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
P3
normal
2 years ago
2 years ago

People

(Reporter: Willian Gustavo Veiga, Unassigned)

Tracking

({nightly-community})

Trunk
nightly-community
Points:
---

Firefox Tracking Flags

(e10s+)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Created attachment 8791340 [details]
1.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20160914030200

Steps to reproduce:

- Open 1.html (attachment) in Firefox Nightly (51.0a1).
- Open your console.
- Click the "Open" button.


Actual results:

popup.innerHeight and popup.innerWidth returns 0. Console output: "Object { innerHeight: 0, innerWidth: 0 }".


Expected results:

popup.innerHeight should be 600 and popup.innerWidth should be 800. Expected console output: "Object { innerHeight: 600, innerWidth: 800 }".
(Reporter)

Updated

2 years ago
Whiteboard: [nightly-community]
(Reporter)

Comment 1

2 years ago
Created attachment 8791346 [details]
2.html

Getting innerHeight and innerWidth with a window.setTimeout call is a possible workaround. Notice that even when you pass 0 or null the problem does not occurs.

This bug is not present in Firefox ESR 45.3.0.

Comment 2

2 years ago
It's an issue with e10s, if you disable e10s in Nightly, it works as expected. The bug is probably here since the first steps of e10s in Firefox.
Blocks: 516752
tracking-e10s: --- → ?
Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
Summary: Popup Window - innerHeight and innerWidth return 0 → [e10s] Popup Window - innerHeight and innerWidth return 0

Comment 3

2 years ago
The page here is trying to retrieve the width and height immediately after calling window.open. In e10s we don't pass this size to the child process, but the parent has this inner width and height by the end of nsWindowWatcher::OpenWindowWithTabParent so we could perhaps pass this down to the child in some manner.

A workaround is to wait for a load event before getting the size.

Note that Chrome has the same issue.
So ... INVALID?
Flags: needinfo?(enndeakin)

Comment 5

2 years ago
I don't think it is invalid. This could be fixed as I described above. It might be wontfix, but I don't feel confident making that call myself.
Flags: needinfo?(enndeakin)

Updated

2 years ago
tracking-e10s: ? → +
(In reply to Neil Deakin (away until Oct 3) from comment #5)
> I don't think it is invalid. This could be fixed as I described above. It
> might be wontfix, but I don't feel confident making that call myself.

Is there anything we want to do here?
Flags: needinfo?(bugs)
We have several people who aren't sure what call to make on this. Neil suggested someone from Layout. Perhaps given the feedback above, smaug can help make the call on the approach (or whether we just wontfix).
Not really layout, but whoever deals with window.open.
This does sound like a bug to fix, but given some other browsers have the same bug, perhaps it isn't urgent.

mconley?
Flags: needinfo?(bugs) → needinfo?(mconley)
This is not urgent, though a fix would be nice. I'd put this in the "P3" bucket of the new priority system.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mconley)
Priority: -- → P3

Updated

2 years ago
Keywords: nightly-community
Whiteboard: [nightly-community]
You need to log in before you can comment on or make changes to this bug.