IGNORE BAD COMMIT MESSAGES because something landed and was backed out for no bug number
--HG--
extra : amend_source : 1134c379d1134fe160fd2d889488d07acd9f4177
Add LOCAL_GL prefix for all GL constant value.
Turn to use GL_RED and GL_RB if we use core profile.
Turn to use GL_RGB_422_APPLE instead of GL_YCBCR_422_APPLE for core profile.
MozReview-Commit-ID: FCwbrUEFUxI
PBrowser::RequestNativeKeyBindings() is used only when somebody tries to
execute native key bindings for synthesized keyboard events. Therefore, it
doesn't need to retrieve edit commands for all editor types. Instead, it
should take the editor type and just return the edit commands for it.
MozReview-Commit-ID: HF4Gz99SBQP
--HG--
extra : rebase_source : e332d2ef5ae36949a9a362d8f95c5d427c9812e7
Now, nsIWidget::ExecuteNativeKeyBinding() isn't used by anybody for executing
edit commands. Instead, they need array of edit commands for the key
combination. So, the method should be renamed to GetEditCommands() and just
return edit commands as an array.
MozReview-Commit-ID: 4G0B1lJ8Lbe
--HG--
extra : rebase_source : 4a5829281d59677c773950c34d91a1cd8074d243
Synthesized keyboard events in child process doesn't have edit commands when
it's being dispatched. With the old design, PuppetWidget needed to store all
edit commands for dispatching keyboard event but it's not necessary now because
WidgetKeyboardEvent will get only necessary edit commands when
WidgetKeyboardEvent::ExecuteEditCommands() is called.
So, PuppetWidget should stop calling TabChild::RequestNativeKeyBindings()
before dispatching keyboard events.
This patch changes browser_audioTabIcon.js which becomes permanent orange with
this change.
MozReview-Commit-ID: 1eK1mUahRMO
--HG--
extra : rebase_source : 13ce4aca8e45fa3d4b739a978bfa7dbddaf58ae3
When eKeyPress event is dispatched from TabParent to a remote process, it
should store edit command for all editor types. Then, copied
WidgetKeyboardEvent in the remote process doesn't need to request the edit
commands when its ExecuteEditCommands() is called.
Note that this patch also changes a automated test, browser_bug1316330.js,
that uses nsIDOMWindowUtils.dispatchDOMEventViaPresShell() to dispatch
repeated keyboard events in the tab. However, it should use synthesizeKey()
to emulate everything of native keyboard events and the API can dispatch
repeated keyboard events too. (And the test has a bug. It tries to wait 0.5
sec when every keydown or keypress event. However, it fails since startTime
is never initialized. This patch fixes this bug too.)
MozReview-Commit-ID: IYhyxqH3Ch8
--HG--
extra : rebase_source : 0db911e8e6ea7fc537bda76f4cc0f8952cc13dd2
Currently, edit commands for native key bindings are stored in widget. This is
stateful and really complicated in content process because it needs to cache
them.
We can make this simpler if we make WidgetKeyboardEvent store edit commands for
the key combination. Then, child process can handle it even if it's delayed
event or it's a nested event.
This patch adds arrays to WidgetKeyboardEvent to store edit commands which are
initialized with nsIWidget::ExecuteNativeKeyBinding() and adds
WidgetKeyboardEvent::ExecuteEditCommands() to execute stored edit commands as
same as nsIWidget::ExecutenativeKeyBinding().
MozReview-Commit-ID: BGRvBrLz5lp
--HG--
extra : rebase_source : b7ecd704d9c331ca1e0aedc66f230114015b853b
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
Mats Palmgren
Wes Kocher
Kartikaya Gupta
JerryShih
Masatoshi Kimura
Jim Chen
Ryan VanderMeulen
Masayuki Nakano
Stephen A Pohl
James Willcox
Nathan Froyd
Nicolas Silva
Emilio Cobos Álvarez
Sebastian Hengst
Michael Layzell
Randall Barker
Jan Beich
Evan Wallace
Birunthan Mohanathas
David Anderson
Iris Hsiao
Kris Maglione
David Anderson