Attached is a mochitest-chrome testcase. 1. apply the diff 2. make -C OBJDIR/dom/tests/mochitest/ 3. cd OBJ _tests/testing/mochitest 4. python runtests.py --chrome --test-path=dom/tests/mochitest/chrome/test_content-document-global-created_bfcache.xul The test opens page 1 in a <browser type="content"/>, which navigates to page 2, which calls history.back() [all navigation is performed from a setTimeout(,0) from a 'load' listener in a page]. The content-document-global-created observer is called 3 times, as expected, but subject.location.toString() is: 1- 1.html - correct 2- 2.html - correct 3- 2.html - incorrect, should be the first page.
> The content-document-global-created observer is called 3 times, as expected, Uh... I'd expect it to be called twice, since there are only two globals involved. We should probably condition the DispatchDOMWindowCreated call at the end of SetNewDocument on !aState, since right now it's dispatching random created notifications when nothing's been created.
blocking2.0: --- → ?
Summary: content-document-global-created notifies with the wrong window.location when navigating back in history to a bfcached page → content-document-global-created notification is sent when nothing has been created
Ah, that makes even more sense. BTW, I meant to also ask about the "setTimeout(,0)" in the testcase, it bothered me a little. Do you have any idea if weird things are expected to happen when navigating directly from onload (I think I saw the new page replacing the current page in session history).
> I think I saw the new page replacing the current page in session history I believe that's the expected behavior when navigating from onload, yeah... Web sites actually depend on this last I checked.
9 years ago
Assignee: nobody → jonas
blocking2.0: ? → beta4+
I'm not sure how to write a testcase when we reuse the inner window. Suggestions welcome.
Checked in to m-c http://hg.mozilla.org/mozilla-central/rev/6140f6313580 We should probably take this on 1.9.2 as well since the notification was added there.
Status: NEW → RESOLVED
blocking1.9.2: --- → ?
Last Resolved: 9 years ago
Resolution: --- → FIXED
Not "blocking" but we'll approve the patch. Is attachment 471712 [details] [diff] [review] the one you want?
blocking1.9.2: ? → -
status1.9.2: --- → wanted
9 years ago
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.