onpopstate event can't work after document.write() is used

REOPENED
Unassigned

Status

()

Core
DOM: Events
REOPENED
5 years ago
5 years ago

People

(Reporter: Owyn Tyler, Unassigned)

Tracking

24 Branch
x86
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36

Steps to reproduce:

1. document.write()
2. window.onpopstate = function( e ) {alert(1);}
3. history.back()


Actual results:

no event firing


Expected results:

alert(1)

Comment 1

5 years ago
Could you upload a minimal testcase
(note, in certain cases webkit/blink based browsers don't have document.write and session history the
way it is specified in HTML spec so this might be related to that).
(Reporter)

Comment 2

5 years ago
Created attachment 823241 [details]
test.html

Comment 3

5 years ago
So document.write in that timeout creates a new window object, and you set listener there.
Then back goes back to the previous window/document-before-write and possible
events fire on that window, not the window object which was created when 
document.write was called.
This is exactly the case where webkit/blink don't follow the spec, so you'll get different behavior there.

As far as I see this is invalid.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
(Reporter)

Comment 4

5 years ago
Created attachment 823455 [details]
test2.html

>and possible events fire on that window
no, it's not firing anywhere and I don't see a way for onpopstate event to possible be triggered after execution of document.write(), here's testpage where event listener is set to window before doing document.write()

Comment 5

5 years ago
Ok, I can see a problem.
Well two problems. The spec has changed (again) after popstate was implemented so
popstate dispatching should be async and SharesDocumentWith doesn't seem to do the right thing
always.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
You need to log in before you can comment on or make changes to this bug.