Open Bug 1052783 Opened 6 years ago Updated 2 years ago

no hashchange event when going back to first history entry of a page created by document.write

Categories

(Core :: DOM: Navigation, defect)

31 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

UNCONFIRMED

People

(Reporter: microrffr, Unassigned)

Details

(Keywords: reproducible, testcase)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

Start at test page:
http://htmlpad.org/writehashchange/#start

Click the "write" button. This uses document.write to create a new page. The new page registers an onhashchange handler that logs events in the developer console.

Click the "test" link. This navigates you to a different anchor, #test. The onhashchange handler runs, logging a message in the console.

Click the back button in the browser. This takes you back to #start.


Actual results:

The onhashchange handler does not run.


Expected results:

The onhashchange handler should run.
Product: Firefox → Core
Hi microrffr,

Sorry for the long delay on a response for the issue. The steps to reproduce are no longer available. Are you still having issues with hashchanges in newer versions of firefox?

Also to note: This may be related to Bug 1237906.
Component: Untriaged → Document Navigation
Flags: needinfo?(microrffr)
Note, document.write ends up creating a new session history entry.
(Last time I tried webkit/blink had broken handling for document.write but IE/Edge/Gecko/Presto behaved ok, IIRC.)
I'm still having this issue on Iceweasel 45.0a2 (2016-01-07)

Here's a new URL for the test page.

https://rawgit.com/wh0/9c19f87821d0b714e510/raw/1380af33fe33bc0c743a6e2b0f6ae35d9fa320fb/index.html#start
Flags: needinfo?(microrffr)

A page does not have to be created by document.write. Run browser from command line with URL (only http not file protocol!) as parameter. The hashchange event does not catch by listener while we are on the first position in history. In Google Chrome it does.

Firefox 65.0. The problem still exists.

You need to log in before you can comment on or make changes to this bug.