Closed
Bug 359674
Opened 18 years ago
Closed 18 years ago
Focused element's state not saved in session history ###!!! ASSERTION: Wrong root: '(nsContentUtils::ContentIsDescendantOf...
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
People
(Reporter: neil, Assigned: sicking)
References
Details
(Keywords: dataloss, regression)
Attachments
(1 file)
1.15 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
This is apparently a regression from bug 358106. Steps to reproduce problem: 1. Disable bfcache 2. Open a page containing a text control e.g. data:text/html,<input> 3. Modify one of the controls, and leave focus in the control 4. Use back/forward buttons to navigate away from the page and back again Expected result: control state stored in session history Actual result: control value lost Additional information: ###!!! ASSERTION: Wrong root: '!aRoot || (nsContentUtils::ContentIsDescendantOf(aStartN, aRoot) && nsContentUtils::ContentIsDescendantOf(aEndN, aRoot))', file c:/trunk/mozilla/content/base/src/nsRange.cpp, line 405 Note that although it is not necessary to disable bfcache to trigger the assertion it is required to reliably demonstrate the session history dataloss.
Comment 1•18 years ago
|
||
With bfcache enabled all you have to do is navigate some in other tabs/windows to cause dataloss... We need to fix this, imo. And we're sure this (not the assert, the dataloss) is a regression from bug 358106?
Flags: blocking1.9?
Comment 2•18 years ago
|
||
Uh, I may have filed bug 359919 as a dupe for the assertion... oops :( Re comment 1: in bug 359919, I clearly showed the new assertion lines (for ContentIsDescendantOf) is what fails.
Assignee | ||
Updated•18 years ago
|
Summary: Focused element's state not saved in session history → Focused element's state not saved in session history ###!!! ASSERTION: Wrong root: '(nsContentUtils::ContentIsDescendantOf...
Assignee | ||
Comment 3•18 years ago
|
||
*** Bug 359919 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 4•18 years ago
|
||
This fixes the assertion and seems to fix the dataloss too. I'll dig a bit further to see why serializing the range failed since the assertion in this case was actually bogus.
Assignee: traversal-range → bugmail
Status: NEW → ASSIGNED
Attachment #245048 -
Flags: superreview?(jst)
Attachment #245048 -
Flags: review?(jst)
Comment 5•18 years ago
|
||
Comment on attachment 245048 [details] [diff] [review] Patch to fix r+sr=jst
Attachment #245048 -
Flags: superreview?(jst)
Attachment #245048 -
Flags: superreview+
Attachment #245048 -
Flags: review?(jst)
Attachment #245048 -
Flags: review+
Assignee | ||
Updated•18 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
Assignee | ||
Comment 6•18 years ago
|
||
*** Bug 360054 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 7•18 years ago
|
||
I can't actually reliably reduce the dataloss part even without the landed patch, so it's hard to tell what exactly failed with serializing the range. It'd be great if someone else could verify that the dataloss issue has actually been fixed on the trunk and if so mark the bug VERIFIED
Updated•11 years ago
|
Component: DOM: Traversal-Range → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•