Bug 177449

Summary:

REGRESSION(r222392): [WPE][GTK] Many forms tests are failing due to broken event timestamps

Product:

WebKit

Reporter:

Michael Catanzaro <mcatanzaro>

Component:

WebKitGTK

Assignee:

Chris Dumez <cdumez>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

benjamin, bugs-noreply, buildbot, cdumez, cmarcelo, commit-queue, dbates, esprehn+autocc, kangil.han, mcatanzaro, zan

Priority:

Keywords:

PlatformOnly, Regression

Version:

Other

Hardware:

OS:

Linux

See Also:

https://bugs.webkit.org/show_bug.cgi?id=177444
https://bugs.webkit.org/show_bug.cgi?id=154246
https://bugs.webkit.org/show_bug.cgi?id=212338

Attachments:

Description	Flags
Proposed patch	none
GTK-specific fix	none
Proposed change	none
Patch	none
Patch	mcatanzaro: commit-queue-
Patch	none
Patch	none
Patch	none
Patch for landing	none
Patch for landing	none

Michael Catanzaro

Reported 2017-09-25 11:50:50 PDT

r222392 "Use high resolution timestamp for event time" broke the following layout tests for GTK: fast/forms/ValidityState-valueMissing-002.html fast/forms/listbox-selection-after-typeahead.html fast/forms/listbox-typeahead-scroll.html fast/forms/onchange-select-check-validity.html fast/forms/select-double-onchange.html fast/forms/select-script-onchange.html fast/forms/select/menulist-oninput-fired.html fast/forms/select/select-disabled.html That's in addition to bug #177444 and bug #177447. Updating expectations accordingly. The failures all look different and weird: --- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/ValidityState-valueMissing-002-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/ValidityState-valueMissing-002-actual.txt @@ -15,8 +15,8 @@ PASS valueMissingFor("select-without-fake-placeholder-size2-multiple") is false Updating valueMissing state by a key input: PASS valueMissingFor("select-selecting-by-key") is true -PASS select.value is "a" -PASS valueMissingFor("select-selecting-by-key") is false +FAIL select.value should be a. Was . +FAIL valueMissingFor("select-selecting-by-key") should be false. Was true. PASS valueMissingFor("select-selecting-by-key-2") is true PASS select.value is "a" PASS valueMissingFor("select-selecting-by-key-2") is false --- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/listbox-selection-after-typeahead-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/listbox-selection-after-typeahead-actual.txt @@ -4,8 +4,8 @@ PASS mouseDownAtOption(1); bitPatternForSelectedOptions() is "0100000" -PASS sendkeyDown("5"); bitPatternForSelectedOptions() is "0000010" -PASS sendkeyDown("upArrow", "shiftKey"); bitPatternForSelectedOptions() is "0000110" +FAIL sendkeyDown("5"); bitPatternForSelectedOptions() should be 0000010. Was 0100000. +FAIL sendkeyDown("upArrow", "shiftKey"); bitPatternForSelectedOptions() should be 0000110. Was 1100000. PASS successfullyParsed is true TEST COMPLETE --- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/listbox-typeahead-scroll-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/listbox-typeahead-scroll-actual.txt @@ -1,4 +1,4 @@ Test for http://bugs.webkit.org/show_bug.cgi?id=13013 REGRESSION: Selection box does not scroll to where the focus jumps when pressing an alphanumeric key. -SUCCESS +FAIL --- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/onchange-select-check-validity-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/onchange-select-check-validity-actual.txt @@ -1,4 +1,4 @@ The select's validity was initially false -The select's validity was changed to true +The select's validity was changed to false --- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/select-double-onchange-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/select-double-onchange-actual.txt @@ -1,5 +1,5 @@ Test for http://bugs.webkit.org/show_bug.cgi?id=13857 REGRESSION: onChange function applied to select element executes twice when focus is set. -SUCCESS +To test interactively, select the other option in the pop up. This text should change to SUCCESS. --- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/select-script-onchange-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/select-script-onchange-actual.txt @@ -1,6 +1,7 @@ Test for http://bugs.webkit.org/show_bug.cgi?id=23721 Changing dropdown's selectedIndex within onchange handler fires another onchange. -SUCCESS + +FAILURE: onchange(2) called 0 times. This select changes on focus: should not fire onchange. This select changes on change: should only fire onchange once. --- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/select/menulist-oninput-fired-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/select/menulist-oninput-fired-actual.txt @@ -2,7 +2,6 @@ Pressing 2 key -PASS PASS successfullyParsed is true TEST COMPLETE --- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/select/select-disabled-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/fast/forms/select/select-disabled-actual.txt @@ -8,9 +8,9 @@ PASS select1.value is "b" PASS select1.value is "b" PASS select2.value is "a" -PASS select2.value is "b" -PASS select2.value is "b" -PASS select2.value is "b" +FAIL select2.value should be b. Was a. +FAIL select2.value should be b. Was a. +FAIL select2.value should be b. Was a. PASS successfullyParsed is true TEST COMPLETE

Attachments
Proposed patch (380 bytes, patch) 2017-09-25 13:23 PDT, Chris Dumez	no flags	Details Formatted Diff Diff
GTK-specific fix (816 bytes, patch) 2017-09-25 13:56 PDT, Chris Dumez	no flags	Details Formatted Diff Diff
Proposed change (3.87 KB, patch) 2017-09-25 14:54 PDT, Chris Dumez	no flags	Details Formatted Diff Diff
Patch (10.21 KB, patch) 2017-09-26 09:24 PDT, Chris Dumez	no flags	Details Formatted Diff Diff
Patch (10.17 KB, patch) 2017-09-26 09:29 PDT, Chris Dumez	mcatanzaro: commit-queue-	Details Formatted Diff Diff
Patch (15.59 KB, patch) 2017-10-02 11:25 PDT, Michael Catanzaro	no flags	Details Formatted Diff Diff
Patch (15.58 KB, patch) 2017-10-02 12:50 PDT, Michael Catanzaro	no flags	Details Formatted Diff Diff
Patch (4.23 KB, patch) 2017-10-03 09:32 PDT, Michael Catanzaro	no flags	Details Formatted Diff Diff
Patch for landing (4.28 KB, patch) 2017-10-04 02:08 PDT, Michael Catanzaro	no flags	Details Formatted Diff Diff
Patch for landing (1.47 KB, patch) 2017-10-04 06:15 PDT, Michael Catanzaro	no flags	Details Formatted Diff Diff
Show Obsolete (9) View All Add attachment proposed patch, testcase, etc.

Chris Dumez

Comment 1 2017-09-25 12:47:16 PDT

I suspect eventSender.keyDown() stopped working for some reason?

Michael Catanzaro

Comment 2 2017-09-25 12:53:00 PDT

*** Bug 177444 has been marked as a duplicate of this bug. ***

Michael Catanzaro

Comment 3 2017-09-25 12:54:19 PDT

Also: fast/events/popup-when-select-change.html

Chris Dumez

Comment 4 2017-09-25 13:13:37 PDT

I wonder if setting the event's time field to GDK_CURRENT_TIME in EventSenderProxy::keyDown() would help (similarly to what is done in EventSenderProxy::createMouseButtonEvent().

Chris Dumez

Comment 5 2017-09-25 13:17:02 PDT

(In reply to Chris Dumez from comment #4) > I wonder if setting the event's time field to GDK_CURRENT_TIME in > EventSenderProxy::keyDown() would help (similarly to what is done in > EventSenderProxy::createMouseButtonEvent(). My bet is that this is caused by GTK's EventSenderProxy failing to set simulated key/mouse event's timestamp in some cases. I need to look into this more but my patch might have changed behavior here because the native event's WallTime now gets converted into a MonotonicTime and I do not know what it does when the WallTime is 0.

Chris Dumez

Comment 6 2017-09-25 13:23:43 PDT

Created attachment 321731 [details] Proposed patch Would you mind testing this?

Chris Dumez

Comment 7 2017-09-25 13:48:32 PDT

Comment on attachment 321731 [details] Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=321731&action=review > Source/WTF/wtf/WallTime.cpp:43 > + if (!m_value) I talked to Phil and we probably would not want to land this. I would still like to know if it fixes the issue for the GTK port to help me understand. Chances are the right fix will be to properly set the event's time in EventSenderProxy (assuming this fixes the issue).

Chris Dumez

Comment 8 2017-09-25 13:56:30 PDT

Created attachment 321736 [details] GTK-specific fix Proposed GTK-specific fix. Please feel free to land this one if it works (I cannot test myself).

Michael Catanzaro

Comment 9 2017-09-25 14:01:52 PDT

Unfortunately I think that patch is a no-op because GDK_CURRENT_TIME is an alias for 0 (actually 0L) and gdk_event_new() ensures the struct is initially zeroed.

Chris Dumez

Comment 10 2017-09-25 14:49:55 PDT

Ok, I think that the simulated PlatformEvents from GTK may be 0 as timestamp (WallTime). When it gets converted to a MonotonicTime, we may end with a negative value when calling WallTime::approximateMonotonicTime(). If we get a negative MonotonicTime value, the following check in TypeAhead::handleEvent() will always be true: if (event->timeStamp() < m_lastTypeTime) return -1; .. because m_lastTypeTime is 0.

Chris Dumez

Comment 11 2017-09-25 14:53:22 PDT

(In reply to Chris Dumez from comment #10) > Ok, I think that the simulated PlatformEvents from GTK may be 0 as timestamp > (WallTime). When it gets converted to a MonotonicTime, we may end with a > negative value when calling WallTime::approximateMonotonicTime(). > > If we get a negative MonotonicTime value, the following check in > TypeAhead::handleEvent() will always be true: > if (event->timeStamp() < m_lastTypeTime) > return -1; > > .. because m_lastTypeTime is 0. I will propose a fix making the code more robust against having PlatformEvent::timestamp() returning 0. However, if this is really the problem, I think the GTK port should make sure to to initialize it with WallTime::now() when it is 0. I think this may be observable by firing an event using eventSender.keyDown() then checking event.timeStamp in JS.

Chris Dumez

Comment 12 2017-09-25 14:54:22 PDT

Created attachment 321746 [details] Proposed change Could someone please let me know if this fixes the issue for GTK?

Build Bot

Comment 13 2017-09-25 14:55:48 PDT

Attachment 321746 [details] did not pass style-queue: ERROR: Source/WebCore/platform/PlatformEvent.h:29: Alphabetical sorting problem. [build/include_order] [4] Total errors found: 1 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style.

Michael Catanzaro

Comment 14 2017-09-25 20:01:16 PDT

(In reply to Chris Dumez from comment #12) > Created attachment 321746 [details] > Proposed change > > Could someone please let me know if this fixes the issue for GTK? Confirmed fixed. Nice, thank you! Will you handle landing it? Note that I added failure expectations for these tests in r222461.

Chris Dumez

Comment 15 2017-09-25 20:13:43 PDT

(In reply to Michael Catanzaro from comment #14) > (In reply to Chris Dumez from comment #12) > > Created attachment 321746 [details] > > Proposed change > > > > Could someone please let me know if this fixes the issue for GTK? > > Confirmed fixed. Nice, thank you! > > Will you handle landing it? > > Note that I added failure expectations for these tests in r222461. I can land it tomorrow but if you’re in a hurry, feel free to land earlier.

Michael Catanzaro

Comment 16 2017-09-25 20:22:00 PDT

No hurry. Thanks. (In reply to Chris Dumez from comment #11) > I will propose a fix making the code more robust against having > PlatformEvent::timestamp() returning 0. However, if this is really the > problem, I think the GTK port should make sure to to initialize it with > WallTime::now() when it is 0. I did a bit of digging. It looks like this already occurs for PlatformKeyboardEvent and PlatformWheelEvent in the constructors for those events (in PlatformKeyboardEventGtk.cpp and PlatformWheelEventGtk.cpp). So not sure what has gone wrong there. PlatformMouseEvent's GTK constructor takes the time instead from the underlying GdkEventMotion using WallTime::fromRawSeconds, which looks wrong because it's passing *milliseconds* into that function. But it looks like these broken tests involved keyboard events, not mouse events.

Chris Dumez

Comment 17 2017-09-26 09:08:52 PDT

(In reply to Michael Catanzaro from comment #16) > No hurry. Thanks. > > (In reply to Chris Dumez from comment #11) > > I will propose a fix making the code more robust against having > > PlatformEvent::timestamp() returning 0. However, if this is really the > > problem, I think the GTK port should make sure to to initialize it with > > WallTime::now() when it is 0. > > I did a bit of digging. It looks like this already occurs for > PlatformKeyboardEvent and PlatformWheelEvent in the constructors for those > events (in PlatformKeyboardEventGtk.cpp and PlatformWheelEventGtk.cpp). So > not sure what has gone wrong there. > > PlatformMouseEvent's GTK constructor takes the time instead from the > underlying GdkEventMotion using WallTime::fromRawSeconds, which looks wrong > because it's passing *milliseconds* into that function. But it looks like > these broken tests involved keyboard events, not mouse events. I believe the issue could be in WebEventFactory::createWebKeyboardEvent(). The GTK version does: WallTime::fromRawSeconds(gdk_event_get_time(event)) I guess gdk_event_get_time(event) may return 0, which for GTK means current time.

Chris Dumez

Comment 18 2017-09-26 09:24:52 PDT

Created attachment 321823 [details] Patch

Build Bot

Comment 19 2017-09-26 09:25:53 PDT

Attachment 321823 [details] did not pass style-queue: ERROR: Source/WebKit/Shared/gtk/WebEventFactory.cpp:151: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] Total errors found: 1 in 7 files If any of these errors are false positives, please file a bug against check-webkit-style.

Chris Dumez

Comment 20 2017-09-26 09:29:39 PDT

Created attachment 321825 [details] Patch

Chris Dumez

Comment 21 2017-09-26 09:30:34 PDT

What about wpe_input_keyboard_event's time. Is it in seconds or milliseconds? Is there a special value meaning CURRENT_TIME? My patch only fixes GTK for now, not WPE.

Build Bot

Comment 22 2017-09-26 09:31:51 PDT

Attachment 321825 [details] did not pass style-queue: ERROR: Source/WebKit/Shared/gtk/WebEventFactory.cpp:151: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] Total errors found: 1 in 7 files If any of these errors are false positives, please file a bug against check-webkit-style.

Michael Catanzaro

Comment 23 2017-09-26 09:36:24 PDT

Thanks a bunch for taking a stab at this, Chris. It's a big help. (In reply to Chris Dumez from comment #21) > What about wpe_input_keyboard_event's time. Is it in seconds or > milliseconds? Is there a special value meaning CURRENT_TIME? My patch only > fixes GTK for now, not WPE. I bet we didn't notice that WPE was broken simply because WPE only runs a small subset of the layout tests. I will ask around to get an answer for WPE. For GTK, I fear that the event timestamp is just some monotonic millisecond timestamp that does not have any relation to real-world time (it's not time since the epoch), so passing it into WallTime will never be right. This is going to need a total rethink. We'll take care of it.

Chris Dumez

Comment 24 2017-09-26 09:43:07 PDT

(In reply to Michael Catanzaro from comment #23) > Thanks a bunch for taking a stab at this, Chris. It's a big help. > > (In reply to Chris Dumez from comment #21) > > What about wpe_input_keyboard_event's time. Is it in seconds or > > milliseconds? Is there a special value meaning CURRENT_TIME? My patch only > > fixes GTK for now, not WPE. > > I bet we didn't notice that WPE was broken simply because WPE only runs a > small subset of the layout tests. I will ask around to get an answer for WPE. > > For GTK, I fear that the event timestamp is just some monotonic millisecond > timestamp that does not have any relation to real-world time (it's not time > since the epoch), so passing it into WallTime will never be right. This is > going to need a total rethink. We'll take care of it. Ok, some more work will be needed to be completely correct if event->time is not a number of ms since Epoch. What's causing the tests failing though seems to be not dealing with GDK_CURRENT_TIME and converting it to WallTime::now() which my patch takes care of. Note that NSEvents on Mac/iOS also do not use a number of seconds since Epoch but rather a number of seconds since the computer booted. Our code deals with this because constructing WebKit's event types.

Michael Catanzaro

Comment 25 2017-09-26 09:54:25 PDT

Comment on attachment 321825 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=321825&action=review > Source/WebKit/Shared/gtk/WebEventFactory.cpp:49 > +static inline WallTime eventTime(const GdkEvent* event) We'll also want to move this to some shared location (maybe PlatformEvent) to avoid the code duplication. > Source/WebKit/Shared/gtk/WebEventFactory.cpp:54 > + return WallTime::fromRawSeconds(timeInMilliseconds / 1000.); And then here we could add a FIXME to figure out how to convert properly from the event timestamp to wall time. It's probably not possible. We might need to just always set the event timestamps to WallTime::now(). I'll wait and see if any of our other developers have a suggestion.

Chris Dumez

Comment 26 2017-09-26 10:01:10 PDT

Yes, maybe you'd want to use WallTime::now() consistently until the event's timestamps can properly be converted. Seems the event's timestamps was already being ignored in a lot of cases.

Michael Catanzaro

Comment 27 2017-09-29 18:11:56 PDT

Still looking into the best approach to this problem. Turns out the timestamps *can* be converted under certain conditions.

Michael Catanzaro

Comment 28 2017-10-02 11:25:33 PDT

Created attachment 322399 [details] Patch

Chris Dumez

Comment 29 2017-10-02 11:33:18 PDT

Comment on attachment 322399 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=322399&action=review > Source/WebCore/platform/gtk/GtkUtilities.h:32 > +WallTime wallTimeForEvent(const GdkEvent*); To avoid having to reinterpret_cast at call sites, it seems like we could use templating no?: WallTime wallTimeForEvent(const GdkEvent*); template<typename GdkEventType> WallTime wallTimeForEvent(const GdkEventType* event) { return MonotonicTime::fromRawSeconds(event->time / 1000.).approximateWallTime(); } // in cpp. WallTime wallTimeForEvent(const GdkEvent* event) { // This works if and only if the X server or Wayland compositor happens to // be using CLOCK_MONOTONIC for its monotonic time, and so long as // g_get_monotonic_time() continues to do so as well, and so long as // WTF::MonotonicTime continues to use g_get_monotonic_time(). return MonotonicTime::fromRawSeconds(gdk_event_get_time(event) / 1000.).approximateWallTime(); }

Michael Catanzaro

Comment 30 2017-10-02 11:39:48 PDT

Good point, that would indeed be nicer.

Michael Catanzaro

Comment 31 2017-10-02 12:50:05 PDT

Created attachment 322413 [details] Patch

Chris Dumez

Comment 32 2017-10-02 15:32:32 PDT

Comment on attachment 322413 [details] Patch r=me

WebKit Commit Bot

Comment 33 2017-10-03 02:50:10 PDT

Comment on attachment 322413 [details] Patch Clearing flags on attachment: 322413 Committed r222776: <http://trac.webkit.org/changeset/222776>

WebKit Commit Bot

Comment 34 2017-10-03 02:50:12 PDT

All reviewed patches have been landed. Closing bug.

Michael Catanzaro

Comment 35 2017-10-03 03:50:57 PDT

This patch was correct and should not be reverted, but it didn't fix the tests like your second patch did. We might need that too. I'm starting a build that will allow me to run layout tests locally to see what's going on in those tests.

Chris Dumez

Comment 36 2017-10-03 08:09:34 PDT

Comment on attachment 322399 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=322399&action=review > Source/WebCore/platform/gtk/GtkUtilities.cpp:65 > + return MonotonicTime::fromRawSeconds(gdk_event_get_time(event) / 1000.).approximateWallTime(); You probably need to deal with the time stamp being 0 here and use WallTime::now() then.

Michael Catanzaro

Comment 37 2017-10-03 08:30:09 PDT

I'll try that. And prepare for another sad rebuild. Stupid header files.... Anyway, the tests all pass if I revert my patch and use yours instead, but they still fail when I apply your patch on top of mine.

Michael Catanzaro

Comment 38 2017-10-03 09:32:55 PDT

Created attachment 322534 [details] Patch

Michael Catanzaro

Comment 39 2017-10-03 09:37:43 PDT

You were right. This is tested on the layout tests and actually works. :) I tried to skip that responsibility this morning due to an unusual build setup that made building WebKit in a manner suitable for running layout tests a bit difficult....

Chris Dumez

Comment 40 2017-10-03 10:03:55 PDT

Comment on attachment 322534 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=322534&action=review > Source/WebCore/platform/gtk/GtkUtilities.cpp:64 > + auto time = gdk_event_get_time(event) / 1000.; I think this would read better as: auto gdkEventTime = gdk_event_get_time(event); if (gdkEventTime == GDK_CURRENT_TIME) return WallTime::now(); return MonotonicTime::fromRawSeconds(gdkEventTime).approximateWallTime(); but it is your call. > Source/WebCore/platform/gtk/GtkUtilities.h:37 > + return time ? MonotonicTime::fromRawSeconds(time).approximateWallTime() : WallTime::now(); ditto. > Source/WebKit/Shared/wpe/WebEventFactory.cpp:83 > + return seconds ? MonotonicTime::fromRawSeconds(seconds).approximateWallTime() : WallTime::now(); ditto.

Chris Dumez

Comment 41 2017-10-03 10:04:41 PDT

Comment on attachment 322534 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=322534&action=review >> Source/WebCore/platform/gtk/GtkUtilities.cpp:64 >> + auto time = gdk_event_get_time(event) / 1000.; > > I think this would read better as: > > auto gdkEventTime = gdk_event_get_time(event); > if (gdkEventTime == GDK_CURRENT_TIME) > return WallTime::now(); > return MonotonicTime::fromRawSeconds(gdkEventTime).approximateWallTime(); > > but it is your call. sorry, should have been: auto gdkEventTime = gdk_event_get_time(event); if (gdkEventTime == GDK_CURRENT_TIME) return WallTime::now(); return MonotonicTime::fromRawSeconds(gdkEventTime / 1000.).approximateWallTime();

Michael Catanzaro

Comment 42 2017-10-04 00:43:55 PDT

(In reply to Chris Dumez from comment #41) > auto gdkEventTime = gdk_event_get_time(event); > if (gdkEventTime == GDK_CURRENT_TIME) > return WallTime::now(); > return MonotonicTime::fromRawSeconds(gdkEventTime / > 1000.).approximateWallTime(); Ah yes, much better! Thanks Chris!

Michael Catanzaro

Comment 43 2017-10-04 02:08:31 PDT

Created attachment 322639 [details] Patch for landing

WebKit Commit Bot

Comment 44 2017-10-04 02:49:28 PDT

Comment on attachment 322639 [details] Patch for landing Clearing flags on attachment: 322639 Committed r222837: <http://trac.webkit.org/changeset/222837>

WebKit Commit Bot

Comment 45 2017-10-04 02:49:30 PDT

All reviewed patches have been landed. Closing bug.

Michael Catanzaro

Comment 46 2017-10-04 06:15:04 PDT

Reopening to attach new patch.

Michael Catanzaro

Comment 47 2017-10-04 06:15:07 PDT

Created attachment 322662 [details] Patch for landing

WebKit Commit Bot

Comment 48 2017-10-04 07:24:44 PDT

Comment on attachment 322662 [details] Patch for landing Clearing flags on attachment: 322662 Committed r222846: <http://trac.webkit.org/changeset/222846>

WebKit Commit Bot

Comment 49 2017-10-04 07:24:46 PDT

All reviewed patches have been landed. Closing bug.

Note You need to log in before you can comment on or make changes to this bug.