Closed Bug 554155 Opened 16 years ago Closed 16 years ago

history.pushState may fire more than one onLocationChange event

Categories

(Core :: DOM: Navigation, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.3a5

People

(Reporter: justin.lebar+bug, Assigned: justin.lebar+bug)

References

(Depends on 1 open bug)

Details

Attachments

(1 file, 3 obsolete files)

Splitting off from bug 550565. nsDocShell::AddState contains an explicit call to FireLocationChange, which is always called. Additionally, AddState sometimes calls SetCurrentURI, which also contains a call to FireOnLocationChange. We should only fire that event once for a given pushState call.
Attached patch Patch v1 (obsolete) — Splinter Review
This has the code which I took out from my latest attachment to bug 550565, plus a testcase.
Attachment #434133 - Flags: review?(Olli.Pettay)
Status: NEW → ASSIGNED
This patch modifies the same makefile as the patch in bug 550565, so it'll apply with conflicts unless you also have that patch applied.
Attached patch Patch v1.1 (obsolete) — Splinter Review
Gets rid of some warnings in the test.
Attachment #434133 - Attachment is obsolete: true
Attachment #434285 - Flags: review?(Olli.Pettay)
Attachment #434133 - Flags: review?(Olli.Pettay)
Comment on attachment 434285 [details] [diff] [review] Patch v1.1 > if (maxStateObjSize < 0) >- maxStateObjSize = 0; >+ maxStateObjSize = 0; Nit, I'd prefer if (maxStateObjSize < 0) { maxStateObjSize = 0; }
Attachment #434285 - Flags: review?(Olli.Pettay) → review+
Attached patch Patch for checkin (obsolete) — Splinter Review
Attachment #434285 - Attachment is obsolete: true
Keywords: checkin-needed
Assignee: nobody → justin.lebar+bug
Comment on attachment 435516 [details] [diff] [review] Patch for checkin >+ gBrowser.addTabsProgressListener(listener, Components.interfaces.nsIWebProgress.NOTIFY_ALL); Is there a reason you need to listen to all location changes in all tabs? Hmm, I guess you can't easily add the progress listener to the tab's linked browser because that requires you to fiddle around with weak references. And adding the progress listener to the tabbrowser itself means making that tab the current tab, which isn't ideal either, I guess...
Rebasing this patch against today's head. Just changed some context in the Makefile.
Attachment #435516 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
Depends on: 912513
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: