Currently, it might happen that two different patches clash for the
same build number for the browsers. In this case, authors might
not even know that they need to rebaseline.
This patch starts adding a second line to `BUILD_NUMBER` files - the
signature and date of the `BUILD_NUMBER` change. These are guaranteed
to clash, so it should not be possible to land patches without
re-baselining them.
We should not stall selector actions because of dialogs
and properly timeout instead. For this, we should not await
the handle.dispose() call because it will never happen
while dialog is shown.
Also, log information about dialogs to make it easier to debug.
Review URL: 42f86e9d77
Currently, if web page has an open context menu, then it won't close.
This prevents browser from quitting.
In stock safari, this behavior can also be observed in a way that
context menu will stay opened even if related page got closed.
While investigating this behavior on Mac, a crucial observation was
that `[NSMenu popUpContextMenu]` is spawning a nested event loop,
keeping reference to `WebContextMenuProxyMac` instance, which in turn
keeps references on associated `NSView` with `WKWebView`.
To exit the loop, we need to explicitly cancel context menu. For this,
this patch adds a method `hide` on `WebContextMenuProxy` that uses
port-specific code to cancel context menu.
Windows part of this patch is somewhat speculative: I didn't check
it, but given the same symptomps, I applied the same solution.
Fixes#2700
We now commit protocol.ts files during the roll.
New utils/roll_browser.js helps with that.
This makes our installation very shallow:
- build installer;
- download browsers.
When innerWindow is restored from the history state, we do not receive
content-document-global-created notification, but would still like to know
that window is now using a different inner window to reset the state.
This introduces a new notification juggler-dom-window-reused.
At the same time, goBack()/goForward() sometimes do not initiate
navigation synchronously, so our check for pendingNaivgationId() does
not work. Instead, we rely on canGoBack, and assume that client will
not need the navigationId synchronously.
