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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: asqueella, Assigned: sicking)
References
Details
(Keywords: testcase)
Attachments
(3 files)
6.48 KB,
patch
|
Details | Diff | Splinter Review | |
8.54 KB,
patch
|
jst
:
review+
|
Details | Diff | Splinter Review |
8.84 KB,
patch
|
Details | Diff | Splinter Review |
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.
Comment 1•14 years ago
|
||
> 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
Reporter | ||
Comment 2•14 years ago
|
||
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).
Comment 3•14 years ago
|
||
> 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 | ||
Updated•14 years ago
|
Assignee: nobody → jonas
blocking2.0: ? → beta4+
Updated•14 years ago
|
blocking2.0: beta4+ → betaN+
Assignee | ||
Comment 4•14 years ago
|
||
Attachment #471711 -
Flags: review?(jst)
Assignee | ||
Comment 5•14 years ago
|
||
I'm not sure how to write a testcase when we reuse the inner window. Suggestions welcome.
Updated•14 years ago
|
Attachment #471711 -
Flags: review?(jst) → review+
Assignee | ||
Comment 6•14 years ago
|
||
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
Comment 7•14 years ago
|
||
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
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•