As Joel noticed recently, MessageManager in firefox doesn't guarantee
message delivery if the opposite end hasn't been initialized yet. In
this case, message will be silently dropped on the ground.
To fix this, we establish a handshake in SimpleChannel to make sure that
both ends are initialized, end buffer outgoing messages until this
happens.
Drive-by: serialize dialog events to only deliver *after* the
`Page.ready` protocol event. Otherwise, we deliver dialog events to the
unreported page.
This should fix current build failure on Mac.
5e1333ea77 is necessary to fix the following compilation error:
CMake Error at Source/cmake/WebKitFeatures.cmake:21 (message):
ENABLE_LEGACY_CSS_VENDOR_PREFIXES is not a valid WebKit option
Call Stack (most recent call first):
Source/cmake/WebKitFeatures.cmake:40 (_ENSURE_IS_WEBKIT_OPTION)
Source/cmake/OptionsWPE.cmake:89 (WEBKIT_OPTION_DEFAULT_PORT_VALUE)
Source/cmake/WebKitCommon.cmake:58 (include)
CMakeLists.txt:173 (include)
We try to avoid closing firefox too early, fearing that this
might terminate clean shutdown sequence.
Usually we assume that `Browser.enable` is called before `Browser.close`
- however, this is not the case in certain tests. So we have to
ensure browser initialization in `Browser.close` as well.
In my local tests, this fixes the Firefox Pipe problem: it looks like
we were closing browser too quickly.
It looks like terminating browser when search service or addon manager is
not fully initialized results in a broken shutdown sequence. As of
today, this results in multiple errors in the browser STDERR. In future,
this might also result in browser stalling instead of terminating.
This starts awaiting search and addon manager termination.
References #3995
Using WebProgressListener events works in all cases. Currently
used `pageshow` event will stop being emitted in future when loading
was stopped with `window.stop()` api.
References #3995
