CompositorInitiallyPaused() uses mNeedsUpdatingEGLSurface. But it is not good. mNeedsUpdatingEGLSurface is set to true in moz_container_set_initial_draw_callback(). If compositor is created before moz_container_set_initial_draw_callback(), compositor is not initially paused. It happens sometimes with popup window.
Differential Revision: https://phabricator.services.mozilla.com/D38200
--HG--
extra : moz-landing-system : lando
This was the order of calls for CompositorOGL+WebRender before this patch:
- PreRender, calls [mView preRender:]
- [compositing happens]
- PostRender, calls [mView postRender:]
And this was the order of calls for BasicCompositor before this patch:
- PreRender, ignored
- StartRemoteDrawing(InRegion)
- [software compositing happens]
- EndRemoteDrawing, calls [mView preRender:], does a GL composition, then calls [mView postRender:]
- PostRender, ignored
After this patch, all paths call [mView preRender:] and [mView postRender:] from
PreRender and PostRender.
This changeset also makes it so that we can't tear down the ChildView while
BasicCompositor compositing is happening.
Differential Revision: https://phabricator.services.mozilla.com/D37915
--HG--
extra : moz-landing-system : lando
This is an existing problem: Whenever you enter DOM fullscreen mode on a
window that has drawsContentsIntoWindowFrame == YES, we drop the information
about whether the title should be shown in the titlebar on top of Gecko's
drawing. Then, when you leave DOM fullscreen again, the freshly-created
ToolbarWindow will have mDrawTitle and titleVisibility set to their default
values: mDrawTitle defaults to NO and titleVisibility defaults to
NSWindowTitleVisible.
The title can be drawn in two different modes:
- If the ChildView is covering the titlebar and drawing it in its OpenGL
context, the ChildView handles the drawing of the title text. That drawing
code respects the window's mDrawTitle field, and ignores titleVisibility.
- If Cocoa is drawing the titlebar, it respects the titleVisibility property.
At the moment, Cocoa's drawing is never visible, because it is covered up by
the ChildView's OpenGL context. As a consequence, the extraneous title is never
actually visible on the screen and the bug doesn't actually cause a visible
glitch.
Once we use CoreAnimation, Cocoa's drawing will become visible, and the wrong
value of the titleVisibility property would become apparent.
Differential Revision: https://phabricator.services.mozilla.com/D26403
--HG--
extra : moz-landing-system : lando
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--HG--
extra : moz-landing-system : lando
In bug 1551961, a WM_NCMOUSELEAVE message handler was added to the Windows widget
backend so that we can detect when the mouse leaves a draggable region (since
draggable regions are hittest'ed as HTCAPTION, and are therefore "non-client").
Inside that message handler, we used the WindowAtMouse handler to determine whether
or not the WM_NCMOUSELEAVE was firing because the mouse was moving off of the
non-client area to client area, or moving out of the window entirely.
For reasons that are not particularly clear, on Windows Aero Glass, when clicking on
one of the min/max/close caption buttons, a WM_NCMOUSELEAVE message fires, and the
::WindowFromPoint call that WindowAtMouse uses causes another WM_NCMOUSELEAVE message
to be queued immediately after, so we end up in this situation where the message
loop is getting spammed by WM_NCMOUSELEAVE messages. Moving the mouse away from
the caption buttons seems to stop the spamming.
We have a function similar to WindowAtMouse called EventIsInsideWindow which
does not use ::WindowFromPoint, and this seems to sidestep the issue, while
being functionally equivalent.
Depends on D37421
Differential Revision: https://phabricator.services.mozilla.com/D37422
--HG--
extra : moz-landing-system : lando
We need to do this in order to not override the mouse cursor that we set in the
widget layer when hit-testing in the non-client region.
We were accidentally overriding before because the PresShell normally queues up a
synthetic mousemove event when the mouse is moving within the client region. That
mousemove cause the EventStateManager to update the cursor to match Gecko's
reckoning of the cursor CSS style of the underlying frame (which overrides the
cursor we may have set in the Windows non-client region hittest - for example,
one of the window resize cursors).
By clearing the mMouseInDraggableArea boolean when transitioning from a draggable
to non-draggable region in the non-client region, we make sure that we process the
WM_MOUSELEAVE message, which sends the eMouseExitFromWidget event into Gecko, which
effectively cancels handling of the synthetic mousemove.
Differential Revision: https://phabricator.services.mozilla.com/D37421
--HG--
extra : moz-landing-system : lando
Previously, `runRemoveContentTest()` was the last test which synthesizes
composition in the `<textarea>`. However, new test order move it to middle
of the other tests. Then, it hits an `MOZ_ASSERT()` in
`TextComposition::EditorWillHandleCompositionChangeEvent()` that detects a
bug. When editable element is removed from the DOM tree during a composition,
editor cannot listen to `eCompositionEnd` event. Therefore, when the editor
gets back, it still has destroyed `TextComposition` and keeps handling new
composition with the old one. Therefore this patch makes
`EditorBase::InstallEventListeners()` forget the destroyed composition.
Differential Revision: https://phabricator.services.mozilla.com/D37061
--HG--
extra : moz-landing-system : lando
For making the scope of variants clearer, make it use `let` instead of `var`.
Differential Revision: https://phabricator.services.mozilla.com/D37057
--HG--
extra : moz-landing-system : lando
This patch also fixes the Home and Sidebar Touch Bar buttons, since using them after customizing showed that they no longer worked.
Differential Revision: https://phabricator.services.mozilla.com/D35085
--HG--
extra : moz-landing-system : lando
To avoid populating the clipboard cache,
`nsContentUtils::IPCTransferableToTransferable` should set the
IsPrivateData flag on the output transferable BEFORE assigning data to
it, not therafter.
This patch includes a new regression test for this specific scenario.
The patch also includes fixes for incorrect IsPrivateData flags in some
other locations with `transferable->Init(nullptr)`, but without unit
tests.
Differential Revision: https://phabricator.services.mozilla.com/D36440
--HG--
extra : moz-landing-system : lando
This patch also fixes the Home and Sidebar Touch Bar buttons, since using them after customizing showed that they no longer worked.
Differential Revision: https://phabricator.services.mozilla.com/D35085
--HG--
extra : moz-landing-system : lando
When long tapping on input element, the behavior of virtual keyboard is different of Chrome. Firefox opens virtual keyboard, but Chrome doesn't.
So I would like to change to same behavior of Chrome.
Also, after this fix, action bar (copy, paste and etc) won't be disappeared immediately after it appears by long tap. Before applying this fix, virtual keyboard is shown, then focused element is scrolled to center. So action bar may be disappeared. But after applying this fix, focused element isn't scrolled. So action bar keeps same position.
Depends on D35991
Differential Revision: https://phabricator.services.mozilla.com/D35992
--HG--
extra : moz-landing-system : lando
Actually, long tap can set focus. But since it uses `nsIFocusManager::FLAG_BYMOUSE` flag, we cannot recognize whether setting focus is by long tap or not.
So I would like to add new flag `FLAG_BYLONGPRESS` and `CAUSE_LONGPRESS` that are by long tap.
Differential Revision: https://phabricator.services.mozilla.com/D35991
--HG--
extra : moz-landing-system : lando
This patch also fixes the Home and Sidebar Touch Bar buttons, since using them after customizing showed that they no longer worked.
Differential Revision: https://phabricator.services.mozilla.com/D35085
--HG--
extra : moz-landing-system : lando