[Webkit-unassigned] [Bug 174633] New: Web Automation: implicit navigations leak frame objects and don't cause browsing context switch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jul 18 09:35:50 PDT 2017


            Bug ID: 174633
           Summary: Web Automation: implicit navigations leak frame
                    objects and don't cause browsing context switch
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit2
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cgarcia at igalia.com
                CC: bburg at apple.com, joepeck at webkit.org

I've noticed this debugging testShouldFocusOnTheReplacementWhenAFrameFollowsALinkToA_TopTargetedPage. The situation is something like this:

1. a frame set is loaded
2. switch frame to any frame in the set
3. get a link from the subframe and click it
4. a new page is loaded in the main frame
5. find an element that is in the new page

from 3 to 4 there's actually a browsing context switch, but web driver doesn't know about it. The subrame from which the navigation happened is still the current browsing context, and it's still referenced in WebAutomationSession (frames are never removed from the maps) and in WebAutomationSessionProxy (the script object is still protected, and pending callbacks if any are nos dispatched, it seems we are leaking the frame in the web process). So, step 5 is still trying to find the element in the previous frame, and since the frame is still alive, the evaluateJavaScriptFunction is called, but the element is not found and returns a no such element error. This would be even more problematic if the previous page had an element matching the find command. I'm not sure how to solve this, if the frame was not leaked in the wen process, at least we could get a no such frame error, and handle it as special case, switching to top level and trying again. Something like that is done in chromium:

if (attempt == 2) {
   // Switch to main frame and retry command if subframe no longer exists.                                                                                                                 

I don't like this approach that much, but if there's no other way, at least we should do it only when error returned is no such frame, (and there's an active browsing context, of course).

Any other ideas? Did you solve that in safaridriver somehow?

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170718/514714d7/attachment-0001.html>

More information about the webkit-unassigned mailing list