People seem to be turning on this pref in the wild and generating crash reports
which are wasting time and energy of people who have better things to do.
MozReview-Commit-ID: 5VfjKaDluYJ
--HG--
extra : rebase_source : fa2237835d842ddb118c6ba6096f6b703aef9d81
Remove the addPluginView and removePluginView methods from
GeckoInterface. Instead, move the JNI calls directly to GeckoApp itself.
GeckoApp then uses GeckoActivityMonitor to find the current activity,
instead of using GeckoAppShell.getGeckoInterface().
MozReview-Commit-ID: 7ym8kuElADV
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
When dragging a `draggable=true` HTML DOM node, if no data is added to the
DataTransfer during the DragStart event, we currently cancel the drag. This is
inconsistent with Chrome's behaviour.
This patch adds a chrome-only (hidden from content) item to the DataTransfer:
application/x-moz-dummy-data. This data is added only when no other data has
been added to the DataTransfer, and the target of the dragstart event was a
draggable=true HTML DOM node.
This hidden node allows for the drag event to complete successfully, while
appearing the same as Chrome's behavior to content scripts.
MozReview-Commit-ID: HVqEr7aR6DD
This patch matches Chrome's behavior almost exactly, except it uses a slightly
different formula for the deltaY value that results in the same movement speed
as Chrome but doesn't drift over time.
Tested by confirming that trackpad pinch zoom now works on maps.google.com,
wego.here.com, and figma.com.
`beginGestureWithEvent` and `endGestureWithEvent` are not called for
applications that link against the macOS 10.11 or later SDK when we're running
on macOS 10.11 or later.
For compatibility with all supported macOS versions, we have to call
{begin,end}GestureWithEvent ourselves based on the event phase when we're using
the 10.11+ SDK.
See: https://developer.apple.com/reference/appkit/nsresponder/1526368-begingesturewithevent
GeckoAppShell.scheduleRestart was called from XPCOM toolkit when we
needed to restart after the Gecko thread exits. But because we made the
"Gecko:Exited" event contain a "restart" flag, we can handle that
entirely in Java now, so we don't need to call
GeckoAppShell.scheduleRestart anymore.
Prior to this patchset, we never hosted remote, scrollable content in widgets
other than toplevel and child windows, so all other widget types have APZ
disabled. Since we now need to host remote content in popup widgets, and would
like similar performance and behavior for those browsers as other remote
browsers, we also need to enable APZ for those widgets too.
MozReview-Commit-ID: AVDt9U5i2WK
When dragging a `draggable=true` HTML DOM node, if no data is added to the
DataTransfer during the DragStart event, we currently cancel the drag. This is
inconsistent with Chrome's behaviour.
This patch adds a chrome-only (hidden from content) item to the DataTransfer:
application/x-moz-dummy-data. This data is added only when no other data has
been added to the DataTransfer, and the target of the dragstart event was a
draggable=true HTML DOM node.
This hidden node allows for the drag event to complete successfully, while
appearing the same as Chrome's behavior to content scripts.
MozReview-Commit-ID: HVqEr7aR6DD
Add a static boolean sThreadDestroyed which can be accessed only on JAVA UI thread.
Set sThreadDestroyed to true at DestroyOnUiThread that will stop remain tasks to access the Bridge() instance at JAVA thread.
MozReview-Commit-ID: 5JtUFgc6Vl3
This part is mainly to mark the channel as urgent-start if src related
attributes in HTMLImageElement and HTMLInputElement is set and the channel is
open due to user interaction. Unfortunately, we cannot just check the event
state just after creating channel since some loading image tasks will be queue
and execute in stable state. Thus, I store the event state in elements and
pass it to the place where create the channel.
MozReview-Commit-ID: GBdAkPfVzsn
--HG--
extra : rebase_source : 715352317b4b600f8a7f78b7bc22b894bb272d27
APZCTreeManager::AdjustScrollForSurfaceShift is only called from the
compositor now, so there is no need to expose this API for callers in
widget code.
MozReview-Commit-ID: BySCQ8N4SuM
This works around a GTK bug that led to the default engine being used instead
for the first draw.
MozReview-Commit-ID: 4r48HNUgVBE
--HG--
extra : rebase_source : 83a964e02dba97cb0b52acde6b692d241c03ed57
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
