This has to be fixed before we ship.
blocking2.0: --- → ?
Looks like nsGenericHTMLElement.cpp also has some bad uses so let have this bug fixing all of them.
Summary: Fix misuses of ContentStatesChanged and MOZ_AUTO_DOC_UPDATE introduced with :valid/:invalid patch → Fix uses of ContentStatesChanged and MOZ_AUTO_DOC_UPDATE in content/html/content/*.cpp
Created attachment 471646 [details] [diff] [review] Patch v1
Attachment #471646 - Flags: review?(bzbarsky)
Comment on attachment 471646 [details] [diff] [review] Patch v1 >+++ b/content/html/content/src/nsGenericHTMLElement.cpp > MakeContentDescendantsEditable(nsIContent *aContent, nsIDocument *aDocument) >+ MOZ_AUTO_DOC_UPDATE(aDocument, UPDATE_CONTENT_STATE, PR_TRUE); Since this function is recursive, we could end up with tons of update begin/ends here in the common case. Why not just do a single update around the call in nsGenericHTMLElement::ChangeEditableState? And maybe file a followup bug to make this iterative instead of recursive? r=bzbarsky with that.
Attachment #471646 - Flags: review?(bzbarsky) → review+
I guess I can add MOZ_AUTO_DOC_UPDATE(document, UPDATE_CONTENT_STATE, PR_TRUE); before the initial MakeContentDescendantEditable call. This might be useless if |aDocument && stateBefore != aContent->IntrinsicState()| is always false but I guess it's better than having it called at each recursion step. I will open a derecursification bug too.
> but I guess it's better than having it called at each recursion step. Right. And I would be surprised if it's always false.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b6
You need to log in before you can comment on or make changes to this bug.