[Webkit-unassigned] [Bug 44079] [Chromium] fast/events/popup-allowed-from-gesture-initiated-form-submit.html causing debug ASSERT
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Apr 14 21:55:51 PDT 2011
https://bugs.webkit.org/show_bug.cgi?id=44079
Charles Reis <creis at chromium.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |creis at chromium.org
--- Comment #1 from Charles Reis <creis at chromium.org> 2011-04-14 21:55:51 PST ---
I ran into this ASSERT in another context, which I think sheds some light on it.
FrameLoaderClientImpl keeps track of whether a redirect is in progress using m_expectedClientRedirect{Src,Dest}. If so, this ASSERT is making sure the url of the next navigation matches the expectation.
However, there's at least two cases where this isn't true. In my case, a navigation can be aborted if the embedder returns PolicyIgnore. That doesn't clean up this m_expectedClientRedirectSrc field, so we fail the ASSERT.
In the case of this layout test, the form submission targets "_blank", causing it to open in a new window. However, at the time of FrameLoader::submitForm, the new frame doesn't exist yet. FrameLoader instead calls scheduleFormSubmission on the current frame, even though the navigation won't occur there. As a result, we end up expecting the redirect in the wrong frame. Any future navigations in the form's frame will fail the ASSERT.
There may be more cases where a redirect doesn't get canceled through the expected approach, so I'm inclined to think the ASSERT is broken. I've put together a patch that changes it into an "if" instead of an assertion, which should make sure we do the right thing in these corner cases.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list