Closed Bug 582176 Opened 14 years ago Closed 14 years ago

content-document-global-created notification is sent when nothing has been created

Categories

(Core :: DOM: Core & HTML, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+
blocking1.9.2 --- -
status1.9.2 --- wanted

People

(Reporter: asqueella, Assigned: sicking)

References

Details

(Keywords: testcase)

Attachments

(3 files)

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.
Assignee: nobody → jonas
blocking2.0: ? → beta4+
Blocks: 546739
blocking2.0: beta4+ → betaN+
Attached patch Patch to fixSplinter Review
I'm not sure how to write a testcase when we reuse the inner window. Suggestions welcome.
Attachment #471711 - Flags: review?(jst) → review+
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: --- → ?
Closed: 14 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: ? → -
No longer depends on: 608669
Depends on: 608669
Depends on: 638292
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: