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

RESOLVED FIXED

Status

()

RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: asqueella, Assigned: sicking)

Tracking

({testcase})

Trunk
x86
Mac OS X
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+, blocking1.9.2 -, status1.9.2 wanted)

Details

Attachments

(3 attachments)

(Reporter)

Description

8 years ago
Created attachment 460459 [details] [diff] [review]
mochitest testcase as a patch

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
(Reporter)

Comment 2

8 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).
> 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+
(Reporter)

Updated

8 years ago
Blocks: 546739

Updated

8 years ago
blocking2.0: beta4+ → betaN+
Created attachment 471712 [details] [diff] [review]
Patch to fix

I'm not sure how to write a testcase when we reuse the inner window. Suggestions welcome.

Updated

8 years ago
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: --- → ?
Last Resolved: 8 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

Updated

8 years ago
No longer depends on: 608669

Updated

8 years ago
Depends on: 608669
Depends on: 638292
You need to log in before you can comment on or make changes to this bug.