<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [GTK] WTR doesn't correctly handle the Escape key"
href="https://bugs.webkit.org/show_bug.cgi?id=144788#c15">Comment # 15</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [GTK] WTR doesn't correctly handle the Escape key"
href="https://bugs.webkit.org/show_bug.cgi?id=144788">bug 144788</a>
from <span class="vcard"><a class="email" href="mailto:mrobinson@webkit.org" title="Martin Robinson <mrobinson@webkit.org>"> <span class="fn">Martin Robinson</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=144788#c13">comment #13</a>)
<span class="quote">> > 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.</span >
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.
<span class="quote">>
> > 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?</span >
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.
<span class="quote">> 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.</span >
Thanks I appreciate you taking the time to look at it.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>