AttachConsole() may change Win32 std handle values if Firefox is launched from
cmd.exe that makes discrepancy between Win32 and CRT. This patch synchronizes
both std handles.
Differential Revision: https://phabricator.services.mozilla.com/D51275
--HG--
extra : moz-landing-system : lando
This patch fixes activation of the :-moz-window-inactive pseudoclass in client side decoration during drag operations. It depends on and complements the fixes provided in support of Bug 1491808.
Obsoletes D50445
Differential Revision: https://phabricator.services.mozilla.com/D51307
--HG--
extra : moz-landing-system : lando
This change addresses two issues with vrhost sending WM_MOUSEWHEEL events:
- The point from the message had an incorrect coordinate origin. Documentation specifices that it should be screen, rather than window/client, origin. Since vrhost only knows about a position in the window, it translates the point before sending the message.
- Gecko ignores the point passed in to the window message and instead uses the point from GetMessagePos. As warnings indicate, this can be incorrect, as is exposed with vrhost. This change now uses this point from the message when available.
Differential Revision: https://phabricator.services.mozilla.com/D51322
--HG--
extra : moz-landing-system : lando
Remove moz_container_get_scale() and use only nsWindow::GdkScaleFactor() to get scale factor for wl_surface and wl_egl_window.
Always set the scale factor when wl_surface / wl_egl_window is queued for rendering.
Differential Revision: https://phabricator.services.mozilla.com/D51252
--HG--
extra : moz-landing-system : lando
Recent Qualcom drivers are exhibiting the same issues as seen in previous
versions when decoding video. Notably:
- Crashes.
- Green frames.
This patch expands our black list to avoid these problems.
Differential Revision: https://phabricator.services.mozilla.com/D51722
--HG--
extra : moz-landing-system : lando
This code was assuming that the only non-opaque parts of compositor rendering would be the
parts of the window that had vibrancy. But now that the default window background is transparent,
we can have non-vibrant parts where we render into transparency. Dialog windows such as sheet
windows are an example of this.
So instead of using the non-vibrant region of the window as its opaque region, we now use
the region that is covered by opaque Gecko layers. This region is a lot more conservative:
For example, the main browser chrome is now entirely transparent, because the chrome's opaque
parts share a layer with its transparent parts.
As a result, this change slightly affects the CALayer partitioning in the main browser window:
The entire browser chrome is now transparent, not just the tab bar.
The web content area is still opaque.
I think this will be fine. The thing I'm most concerned about is that scrolling inside web
content might cause invalidations of pixels from the chrome, because then we'd recomposite
the CALayers that cover the vibrant tab bar. This doesn't seem to happen most of the time
though, from what I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D51466
--HG--
extra : moz-landing-system : lando
Now that there is no Gecko-contributed background color in the window any more,
there's nothing that needs to be cleared away. This simplifies things.
Differential Revision: https://phabricator.services.mozilla.com/D51464
--HG--
extra : moz-landing-system : lando
With -moz-appearance: dialog now always being transparent, setting up our own
vibrant views for sheet windows is no longer necessary. We now let the regular
sheet window background show through, and that background is already vibrant.
Differential Revision: https://phabricator.services.mozilla.com/D51462
--HG--
extra : moz-landing-system : lando
The window background will be contributed by the widget itself, which renders
them underneath Gecko's rendering.
As a result, -moz-appearance: dialog is now equivalent to the combination
-moz-appearance: none; background-color: transparent.
This change does not turn the widget itself transparent because nsCocoaWindow
does not allow top level windows to become transparent (ever since bug 1162649).
If we ever add support for top level widgets with transparent backgrounds again,
we will probably want to treat -moz-appearance: dialog differently from
-moz-appearance: none; background-color: transparent, but for now this is fine.
This change means that Gecko's rendering will go into transparent buffers. This
may result in some loss of subpixel AA in various cases.
In the main browser window, there are CSS backgound colors that cover all the
non-vibrant areas of the window, so in that window we still render mostly onto
opaque pixels.
Differential Revision: https://phabricator.services.mozilla.com/D51461
--HG--
extra : moz-landing-system : lando
On macOS, the OS window always comes with an opaque background for top level
windows. This is the case even if Gecko determines the root element of the
window to be transparent: Ever since bug 1162649, nsChildView/nsCocoaWindow
ignore calls to SetTransparencyMode for top level windows and always stay opaque.
Returning true from nsChildView::WidgetPaintsBackground() lets us indicate that
we do not need an opaque backstop color to be added at the bottom of the display
list. This backstop color would interfere with vibrant -moz-appearance rendering
under the new vibrancy model.
WidgetPaintsBackground() is only called in one place, in ComputeBackstopColor():
```
nscolor PresShell::ComputeBackstopColor(nsView* aDisplayRoot) {
nsIWidget* widget = aDisplayRoot->GetWidget();
if (widget && (widget->GetTransparencyMode() != eTransparencyOpaque ||
widget->WidgetPaintsBackground())) {
// Within a transparent widget, so the backstop color must be
// totally transparent.
return NS_RGBA(0, 0, 0, 0);
}
// Within an opaque widget (or no widget at all), so the backstop
// color must be totally opaque. The user's default background
// as reported by the prescontext is guaranteed to be opaque.
return GetDefaultBackgroundColorToDraw();
}
```
On Windows 7, the widget returns eTransparencyBorderlessGlass from
GetTransparencyMode(), which also avoids the backstop color.
Differential Revision: https://phabricator.services.mozilla.com/D51458
--HG--
extra : moz-landing-system : lando
Drawing vibrancy fill colors was necessary in the past because we were erasing
the fill color that was drawn by the system, through our override of the
drawRect method of our NSVisualEffectView subclass.
However, starting with changeset be263e3d8bdfc0b6c072ffad2736999b9652d036
(from bug 1491445), we no longer override drawRect. Moreover, since the switch
to Core Animation, there is no way to clear the system's vibrancy fill drawing.
So we don't need to draw the vibrancy fill color any more. In fact, we should
stop drawing it, because now we're double-drawing it.
The fill color is very translucent so the double-drawing is not visually obvious.
Differential Revision: https://phabricator.services.mozilla.com/D51456
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
Behind a pref to ensure that we can turn this off pretty easily if it has perf
impact.
I want to leave the repainting stuff to another bug to land separately, to track
potential (though I hope not!) perf regressions more easily.
Differential Revision: https://phabricator.services.mozilla.com/D50704
--HG--
extra : moz-landing-system : lando
Split off of Bug 1590894
Rename these to support unprefixed version
Also add alias to keep compatibility
Differential Revision: https://phabricator.services.mozilla.com/D50989
--HG--
extra : moz-landing-system : lando
Add IsDMABufBuffer identification to WindowBackBuffer
Use two sets of wayland buffers (shm and dmabuf) and use dmabuf for fullscreen updates only
when dmabuf is enabled.
Split GetWaylandBufferToDraw() to GetWaylandBufferRecent() and GetWaylandBufferWithSwitch()
to better reflect actual function.
Add CreateWaylandBuffer() to create and store Wayland buffer and use it at SetNewWaylandBuffer()
to change an active wayland buffer or create a new one.
When CACHE_MISSING image cache is selected we draw directly to wayland buffer if it's available
and cache drawing when wayland buffer is missing only. That produces flickering when small buffer parts are
sent to compositor early and the buffer is blocked for further rendering.
This patch enables direct rendering of bigger screen parts only (like page scrolling) to eliminate small
buffer updates.
Differential Revision: https://phabricator.services.mozilla.com/D50055
--HG--
extra : moz-landing-system : lando
The patch permits to resize compositor window's size after ::SetParent() call to prevent a conflict between ::SetParent() and ::SetWindowPos(). Then it triggers a composite after SetParent() call to resize compositor window correctly.
Differential Revision: https://phabricator.services.mozilla.com/D49884
--HG--
extra : moz-landing-system : lando
Lots of these callbacks have a non-`void*` final parameter, which UBSAN
complains about. This commit changes them to have a `void*` parameter.
This requires undoing the machinery added in the first two commits of bug
1473631: `TypePrefChangeFunc` and `PREF_CHANGE_METHOD`. The resulting code is
simpler (which is good) and more boilerplate-y (which is bad) but avoids the
undefined behaviour (which is good).
Differential Revision: https://phabricator.services.mozilla.com/D50901
--HG--
extra : moz-landing-system : lando
This obviously only improves the situation when a subsequent window is the
same size as the last window that was opened.
Differential Revision: https://phabricator.services.mozilla.com/D50527
--HG--
extra : moz-landing-system : lando
This stores the clipboard even if it was set in a GTK dialog.
Depends on D50764
Differential Revision: https://phabricator.services.mozilla.com/D50765
--HG--
extra : moz-landing-system : lando
This notifies GTK that the data is no longer available for clipboard_get_cb(),
so that GTK will no longer advertise nor attempt to store the data.
Differential Revision: https://phabricator.services.mozilla.com/D50764
--HG--
extra : moz-landing-system : lando
Masatoshi Kimura
Razvan Maries
Martin Stransky
Jim Mason
thomasmo
Coroiu Cristina
Moritz Birghan
Brindusan Cristian
Bryce Seager van Dyk
Markus Stange
Brendan Dahl
Elliot Stirling
Mike de Boer
harry
Jan Horak
Mihai Alexandru Michis
Emma Malysz
Dorel Luca
Emilio Cobos Álvarez
Sam Mauldin
Cosmin Sabou
sotaro
Csoregi Natalia
Nicholas Nethercote
Aaron Klotz
Lee Salzman
Karl Tomlinson
Daniel Varga