Closed Bug 1492818 Opened 6 years ago Closed 2 years ago

After resizing the browser, the page is not reloaded and the resulted empty space becomes unusable.

Categories

(Core :: DOM: Navigation, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox62 --- affected
firefox63 --- affected
firefox64 --- affected

People

(Reporter: obotisan, Unassigned)

Details

Attachments

(1 file)

[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.
Whiteboard: [webcompat][needsdiagnosis]
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.
Component: General → Document Navigation
Flags: needinfo?(kyle)
Product: Firefox → Core

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. :)

Flags: needinfo?(kyle) → needinfo?(bugs)

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.

Flags: needinfo?(bugs) → needinfo?(bzbarsky)

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.

Flags: needinfo?(bzbarsky)
Priority: -- → P3

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

See bug 1547409. Moving webcompat whiteboard tags to keywords.

(it would be nice to know if more than this single site relies on this quirk)

Webcompat Priority: ? → revisit
Whiteboard: [webcompat][needsdiagnosis]

The site now "works" - as in it force-reloads after resize.

Status: NEW → RESOLVED
Closed: 2 years ago
Webcompat Priority: revisit → ---
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: