[Webkit-unassigned] [Bug 144788] [GTK] WTR doesn't correctly handle the Escape key

[bugzilla-daemon at webkit.org]

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

--- Comment #15 from Martin Robinson <mrobinson at webkit.org> ---
(In reply to comment #13)

> > The
> > reason we need to handle this between tests is that not all tests dismiss
> > their context menus, and context menus don't disappear between page loads
> > (you can verify this by test it in minibrowser).
> 
> That sounds to me like a bug in the web view/page proxy, not in WTR.

I don't think it's a bug. I confirmed that Safari and Chromium worked this way as well. You can confirm yourself by going to a page and running "setTimeout(function() { window.history.back(); }, 1500);" and then open up the context menu before the page goes back.

> 
> > There are many tests that do not dismiss the context menu explicitly. For
> > instance look at editing/spelling/context-menu-suggestions.html.
> > 
> > Your escape key approach looks interesting, but really the escape key is
> > just going to call gtk_menu_popdown, so I prefer to just do that directly.
> > The reason is that the test harness is basically a machine that eats key
> > events and poops out test expectations. I feel nervous sending it another
> > key event, after again spending hours, running layout tests and looking at
> > results. 
> 
> My main concern with your approach is that it's very GTK+ specific, what
> makes me wonder if the problem is not in WTR but in the web view, and by
> fixing it in WTR we are just hiding the actual bug even more. Why do other
> ports don't need this?

I believe what is going on here is that the Mac EventSender send its events directly to the widget, while we use the main GTK+ event queue. I think in the long term we should try for an approach more like that and remove the work-arounds. It's unclear if we can do that without abusing the GTK+ API though.

> I'm not blocking anything, just proposing a possible simpler alternative,
> but you already confirmed it's not enough and it's a related but different
> issue, and that's why I opened this bug. I just need to understand the
> problem and make sure this is not a work around of an actual bug before
> reviewing the patch. I understand your frustration, though.

Thanks I appreciate you taking the time to look at it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150508/d59f8460/attachment.html>