After resizing the browser, the page is not reloaded and the resulted empty space becomes unusable.
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
People
(Reporter: obotisan, Unassigned)
Details
Attachments
(1 file)
1.59 MB,
image/gif
|
Details |
[Affected versions]: - Firefox 62.0 - Firefox 63.0b7 - Firefox 64.0a1 [Affected platforms]: - Windows 10 x64 - Ubuntu 16.04 x64 - macOS 10.13 [Steps to reproduce]: 1. Open http://histography.io/ 2. Resize the browser. 3. Observe the behaviour. [Expected result]: - There is an empty space on the page that can't be used. [Actual result]: - The page is refreshed and the history line is displayed on the entire page. [Regression range]: - I don't think is a regression, but I couldn't find out, because this site doesn't work on builds that are previous to Nightly from 2018-08-17. [Additional notes]: - This issue is not reproducing on Chrome. - Please look at the attached gif to see the bug reproducing.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
The webpage only "works" in chrome because it calls location.reload() from the resize event handler. Doing so in Firefox seems to be blocked / not working. Though also, the site doesn't seem to have any backoff for this, so if you fire a bunch of resize events while the user is dragging the window, it'll just keep calling the resize handler as/when it gets attached. A site workaround would be doing something like: var resizeReloadTimeout = 0; window.addEventListener("resize", function() { if (resizeReloadTimeout) { clearTimeout(resizeReloadTimeout); } resizeReloadTimeout = setTimeout(() => location.reload(), 100); }); There might still be a DOM/docshell bug here, though it's also possible we deliberately break navigating mid-resize. Maybe qdot can help.
Comment 2•5 years ago
|
||
I'm not real sure how this part of the event system works, so forwarding to smaug, who is welcome to forward back to me and tell me to figure it out if they're not familiar with this either. :)
Comment 3•5 years ago
|
||
So, https://searchfox.org/mozilla-central/rev/6c784c93cfbd5119ed07773a170b59fbce1377ea/dom/base/Location.cpp#753-759
Since that particular code has r=bz, perhaps he remembers something about that - hey it was just 14+ years ago ;)
But I think we should remove that code, assuming others don't have similar behavior.
Comment 4•5 years ago
|
||
Hrm. So like the comment says, this was a somewhat common stupid thing for sites to do back in the day. Often after browser-sniffing for "Netscape" or "Not IE".
The HTML spec at https://html.spec.whatwg.org/multipage/history.html#dom-location-reload says:
If the currently executing task is the dispatch of a resize event in response to the user resizing the browsing context
Repaint the browsing context and return.
which is what we implement, basically.
That said, I did just test Chrome and Safari and neither of them seems to do this. So we could try removing this code, yes, and hope people aren't doing weird browser-sniffing stuff around this anymore... If we do that, we should get the spec updated too.
Updated•5 years ago
|
Comment 5•5 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 6•5 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Comment 7•5 years ago
|
||
See bug 1547409. Moving webcompat whiteboard tags to keywords.
Comment 8•4 years ago
|
||
(it would be nice to know if more than this single site relies on this quirk)
Comment 9•2 years ago
|
||
The site now "works" - as in it force-reloads after resize
.
Description
•