[webkit-reviews] review requested: [Bug 45369] Need to check the target frame and restore the right gesture state during the asynchronous history navigation : [Attachment 67396] patch v2

[bugzilla-daemon at webkit.org]

Johnny Ding <jnd at chromium.org> has asked  for review:
Bug 45369: Need to check the target frame and restore the right gesture state
during the asynchronous history navigation
https://bugs.webkit.org/show_bug.cgi?id=45369

Attachment 67396: patch v2
https://bugs.webkit.org/attachment.cgi?id=67396&action=review

------- Additional Comments from Johnny Ding <jnd at chromium.org>
(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.