[Webkit-unassigned] [Bug 174633] Web Automation: implicit navigations don't cause browsing context switch

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Brian Burg from comment #1)
> (In reply to Carlos Garcia Campos from comment #0)
> > 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.
> 
> Great investigation!
> 
> > I'm not sure how to
> > solve this, if the frame was not leaked in the web 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.  
> > 
> >    session->SwitchToTopFrame();
> > }
> > 
> > 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?
> 
> No we haven't solved this. This is probably the cause of many nonspecific
> bugs we get with unexpected "element not found" errors.
> 
> What about changing the context in
> WebAutomationSession::navigationOccurredForPage() if needed, and sending a
> notification out to the driver that the current top level context changed?

I think we can simply clear the m_handleWebFrameMap there, because no frames can be resolved before the page loads, any frame cached there at that point is for previous page. Then, any operation on a stale frame will end up on a non such frame error.

-- 
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/20170720/8e83d7d0/attachment.html>