* This changes the archive.sh script to use the webkit generate-bundle
tool to generate the MiniBrowser bundles instead of using our custom
logic.
* pw_run.sh is simplified because the new bundles include a wrapper
script that sets the needed LD_LIBRARY_PATH environment variables.
pw_run.sh now calls this wrapper script (for GTK or WPE) instead of
calling the MiniBrowser binary directly when running from a bundle.
Co-authored-by: Andrey Lushnikov <aslushnikov@gmail.com>
This establishes a single naming for all our blobs with browser
builds that we upload to CDN: `<browser-name>-<os-version>`
- `<browser-name>` is either `firefox` or `webkit`.
- `os-version` is the OS that was used to produce the build.
References #2745
This patch:
- specializes "linux" scripts into "Ubuntu 18.04" scripts
- renames all future linux blobs on CDN:
* `firefox-linux.zip => firefox-ubuntu-18.04.zip`
* `minibrowser-gtk.zip => minibrowser-gtk-ubuntu-18.04.zip`
* `minibrowser-wpe.zip => minibrowser-wpe-ubuntu-18.04.zip`
* `minibrowser-gtk-wpe.zip => minibrowser-gtk-wpe-ubuntu-18.04.zip`
- updates downloader to deal with the new names
References #2745
This patch changes the build system to use the JHBuild minimal dependency
system introduced in WebKit r264092 <https://trac.webkit.org/r264092>
The build has been tested with Ubuntu-18.04
The binary size of the zip bundles is now: 37M (WPE) and 40M (GTK).
Previously it was 54M and 59M (respectively)
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.
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
