[Webkit-unassigned] [Bug 45369] Need to check the target frame and restore the right gesture state during the asynchronous history navigation

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Sep 13 04:19:42 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=45369


Johnny Ding <jnd at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #67396|                            |review?
               Flag|                            |




--- Comment #6 from Johnny Ding <jnd at chromium.org>  2010-09-13 04:19:42 PST ---
Created an attachment (id=67396)
 --> (https://bugs.webkit.org/attachment.cgi?id=67396)
patch v2

(In reply to comment #5)

> It's lame that we need to find the targetFrame again.  What if we get a different answer the second time?  Can we move this check closing to where we actually know the targetFrame?

Thanks, Adam. I agree with you that we need to put the the check in right place.
So the way is to check the name of targetFrame in where we actually know the targetFrame as early as possible, like currently WebKit  puts block popup logic in the following situations,

a). window.open,  WebKit checks the name of targetFrame immediately in DOMWindow:open before starting creating the window and loading the URL.
b). form.submit, WebKit checks the name of targetFrame in FrameLoader::submitForm before adding it to RedirectScheduler
c). history.go(0) (what this patch wants to do),  so I guess I should put the logic in RedirectScheduler::scheduleHistoryNavigation before starting the RedirectScheduler.

Please take a look at the new patch.

-- 
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