Summary: | Assertion failure (SHOULD NEVER BE REACHED) going back on YouTube | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Matt Lilek <dev+webkit> | ||||||||
Component: | Forms | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | mitz | ||||||||
Priority: | P1 | Keywords: | HasReduction | ||||||||
Version: | 523.x (Safari 3) | ||||||||||
Hardware: | Mac | ||||||||||
OS: | OS X 10.4 | ||||||||||
Attachments: |
|
Description
Matt Lilek
2007-06-25 18:02:48 PDT
Created attachment 15313 [details]
Reduction
Created attachment 15383 [details]
Avoid restoring state for elements that do not register for saving state
The layout test works on release builds as well (i.e. fails without the patch).
Comment on attachment 15383 [details]
Avoid restoring state for elements that do not register for saving state
This registersWithDocument function can be private rather than protected, because you don't need access to a function to override it.
But it also seems more robust to me to have HTMLGenericFormElement::closeRenderer check the hash table in the document rather than have a virtual function that has to be kept in sync with the registerFormElementWithState call. Maybe a function called hasFormElementWithState or isFormElementWithStateRegistered in Document. To be called in closeRenderer.
Comment on attachment 15383 [details]
Avoid restoring state for elements that do not register for saving state
Going to do it the way Darin suggested.
Created attachment 15397 [details]
Avoid restoring state for elements that did not register for saving state
The reason I didn't do it this way in the first place is that I mistakenly thought that closeRenderer() was called before the element registered if it wanted to. That's not the case, and this patch is indeed smaller, simpler and more future-proof.
Comment on attachment 15397 [details]
Avoid restoring state for elements that did not register for saving state
r=me
|