The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 941298157e7c82f420cf50ce057154ce9b85301c
extra : source : 189dc8a359815e059a4a217f788d183260bb2bfe
PowerOfTwo makes for a cleaner and more expressive interface, showing that the
profiler will use a power-of-2 storage size.
Using PowerOfTwoMask in ProfilerBuffer also makes it more obvious that we want
cheap modulo operations.
And we don't need to keep the original capacity, as it's only used once and can
easily be recomputed from the mask.
Differential Revision: https://phabricator.services.mozilla.com/D36027
--HG--
extra : moz-landing-system : lando
PowerOfTwo makes for a cleaner and more expressive interface, showing that the
profiler will use a power-of-2 storage size.
Using PowerOfTwoMask in ProfilerBuffer also makes it more obvious that we want
cheap modulo operations.
And we don't need to keep the original capacity, as it's only used once and can
easily be recomputed from the mask.
Differential Revision: https://phabricator.services.mozilla.com/D36027
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
On android, android's nsWindow creates LayerManaer only in nsWindow::Create(). When WebRender error happened, gecko just stopped rendering by disabling Webrender.
The nsWindow needs to re-create LayerManager during disabling Webrender. Further, during disabling WebRender, All GeckoSurfaceTextures should not be attached to GLContext. It is for preventing a conflict with AttachToGLContext() call in SurfaceTextureHost::EnsureAttached().
Differential Revision: https://phabricator.services.mozilla.com/D26687
--HG--
extra : moz-landing-system : lando
App units of a remote browser element in the parent process are
different from app units inside the remote content in the child
process. We should apply the appropriate conversions by exposing
the relevant data as LayoutDevicePixel.
Differential Revision: https://phabricator.services.mozilla.com/D35334
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Previously we were hardcoding to disable on AMD. Modern MacOS versions
don't have MSAA corruption, and anything we find that does should go on
the downloadable blocklist instead.
Differential Revision: https://phabricator.services.mozilla.com/D34986
--HG--
extra : moz-landing-system : lando
This change was suspect to not work under full page zoom, but I thought it
would be okay as it would only affect OOP-iframes. That was not true.
Differential Revision: https://phabricator.services.mozilla.com/D35190
--HG--
extra : moz-landing-system : lando
That includes changing privacy.resistFingerprinting to a non-VarCache pref,
because it doesn't need to be a VarCache.
Differential Revision: https://phabricator.services.mozilla.com/D36162
--HG--
extra : rebase_source : 6d742e6ff2a4b786cb21f6e8874d1fd4bbde1857
The patch also removes the layers.mlgpu.enable-container-resizing pref, because
it's dead.
Differential Revision: https://phabricator.services.mozilla.com/D36159
--HG--
extra : rebase_source : e215d584aed18f865d2e8d00a78e76e9b0323e6e
Even if we don't have a root displayport, the composition size is still used for
displayport margins calculations. For extremely tall iframes, this will create
a displayport that is way to big. We should instead report a composition size that
is equivalent to the visible rect for OOP-iframes.
Differential Revision: https://phabricator.services.mozilla.com/D34528
--HG--
extra : rebase_source : 1f43cb16a0841eb3cd892401c83a46d56276cf2e
- Don't block all drawing until whole screen was painted, clear the screen and
allow partial drawing instead.
- Detect window resize and allow partial drawing directly to wayland buffer in this case.
- Remove backbuffer copy - wait to buffer release instead.
Depends on D33910
Differential Revision: https://phabricator.services.mozilla.com/D33911
--HG--
extra : moz-landing-system : lando
- Add widget.wayland_dmabuf_backend.enabled
- Expose it to Wayland backend by WaylandDisplay object
- Add more logging to Wayland DMABuf backend
Differential Revision: https://phabricator.services.mozilla.com/D33919
--HG--
extra : moz-landing-system : lando
To run task_for_pid() on child processes, we need the child task port for
security reasons. This port can be obtained via a Mach IPC exchange.
This is what GeckoChildProcessHost::GetChildTask() provides, so we use it
in cocoa's version of GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D25927
--HG--
extra : moz-landing-system : lando
- Add widget.wayland_dmabuf_backend.enabled
- Expose it to Wayland backend by WaylandDisplay object
- Add more logging to Wayland DMABuf backend
Differential Revision: https://phabricator.services.mozilla.com/D33919
--HG--
extra : moz-landing-system : lando
- Don't block all drawing until whole screen was painted, clear the screen and
allow partial drawing instead.
- Detect window resize and allow partial drawing directly to wayland buffer in this case.
- Remove backbuffer copy - wait to buffer release instead.
Depends on D33910
Differential Revision: https://phabricator.services.mozilla.com/D33911
--HG--
extra : moz-landing-system : lando
To run task_for_pid() on child processes, we need the child task port for
security reasons. This port can be obtained via a Mach IPC exchange.
This is what GeckoChildProcessHost::GetChildTask() provides, so we use it
in cocoa's version of GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D25927
--HG--
extra : moz-landing-system : lando
Because of the way the canvas 2D implementation juggles between path builders and paths, we have to keep track of current and first points in the path, in case a builder is created out of it.
Differential Revision: https://phabricator.services.mozilla.com/D33757
--HG--
extra : source : c79b3af2395894b449731fccdd9eb006b4d0189e
gfxPlatform::GetSourceSurfaceForSurface and CreateDrawTargetForSurface
are both static methods that we sometimes use via the pattern
gfxPlatform::GetPlatform()->... This is problematic because this forces
gfxPlatform to be initialized in the process, and in the GPU process, we
don't support this. It should be safe to call these methods without
initializing gfxPlatform, so this patch removes the GetPlatform() call.
GetSourceSurfaceForSurface may end up initializing gfxPlatform anyways,
depending on whether or not a DrawTarget was given. This should not be a
concern for the crashes observed in bug 1435586.
Differential Revision: https://phabricator.services.mozilla.com/D33785
Make nsIWebBrowserPrint included unconditionally for addressing nsIDocShell.rs build failure.
Remove direct_call of PPrinting and PRemotePrintJob. Their ipdl are built unconditionally, but their derived classes are not built with --disable-printing.
Differential Revision: https://phabricator.services.mozilla.com/D33391
--HG--
extra : moz-landing-system : lando
- Implement WaylandDMABufSurface class which provides basic 2D surfaces located at GPU memory.
- Implement ability to bind it as wl_buffer for direct wayland rendering and R/W mapping for CPU
Differential Revision: https://phabricator.services.mozilla.com/D33597
--HG--
extra : moz-landing-system : lando
`cmd_align` is always with `nsCommandParams` when it's executed. However,
when somebody checks whether the command is enabled or not, or retrieves the
state, `GetInternalCommand()` is called without `nsCommandParams`. Therefore,
even when `nsCommandParmas` is nullptr for `cmd_align`, `GetInternalCommand()`
shouldn't warn it.
Additionally, internal command supports to set `align` to empty string.
Therefore, `GetInternalCommand()` also needs to support it.
This patch adds `Command::FormatJustify` for the former case and
`Command::FormatJustifyNone` for the latter case.
Note that this does not affect to actual behavior since `AlignCommand`
does not refer the result of `GetInternalCommand()`.
Differential Revision: https://phabricator.services.mozilla.com/D33604
--HG--
extra : moz-landing-system : lando
- Implement nsGbmLib object which binds symbols run-time from libgbm.so library.
- Load available DRM pixel formats from Wayland registry and store related modifiers at WaylandDisplay object.
- Implement Gbm device setup at WaylandDisplay.
Differential Revision: https://phabricator.services.mozilla.com/D32633
--HG--
extra : moz-landing-system : lando
It's only moved around, but not actually used anywhere.
I have no idea what this was supposed to control in the past but it doesn't seem
useful to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D33393
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
When transparent popup window is rendered clear window background to clear
visual artifacts and bold shadows over the popup.
Differential Revision: https://phabricator.services.mozilla.com/D33155
--HG--
extra : moz-landing-system : lando
Note that this makes Firefox use the standard system Print dialog as opposed
to just removing our "Frames" section from our custom dialog.
Differential Revision: https://phabricator.services.mozilla.com/D33389
--HG--
extra : rebase_source : a6d85b5c57bbc3ecd83135dae2581db56e8a7fab
The 85 pixel change in y-axis offset is the distance between the "Print
Background Images" checkbox and (removed) "Each Frame on Separate Pages" radio
button.
Differential Revision: https://phabricator.services.mozilla.com/D33379
--HG--
extra : rebase_source : ca0aa5291f1631a40fba18e22cf609a0768cbdb3
- Rename recent WindowBackBuffer class to WindowBackBufferShm to clearly state that it uses Shm memory to store the pixel buffer.
- Implement WindowBackBufferDMABuf which stores pixel data in GPU memory in WaylandDMABufSurface object.
- Use WaylandDMABufSurface as a wayland backend when DMABuf is available and gfx.wayland_dmabuf_backend.enabled is set.
- Implement WindowImageSurface which temporary stores front buffer pixel data. It's used when front buffer is used by compositor and we want to draw.
Instead of the front/back buffer flip and read-back data from front buffer, don't flip, store the drawing and draw the pixels when compositor
releases the front buffer.
Differential Revision: https://phabricator.services.mozilla.com/D32635
--HG--
extra : moz-landing-system : lando
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
When user moves focus to an editable content in a content process, it posts
IME-focus notification to the main process. Then, when the main process
prepares IME/keyboard handling in editable content, it posts back IME
notification requests to the content process. Then, the content process's
`PuppetWidget` modifies its IME notification requests, but **not** modifying
cache of IME notification requests in its `TextEventDispatcher`. Therefore,
`IMEContentObserver` keep referring older IME notification requests which are
initialized without IME-focus. Note that `IMEContentObserver` caches the
*reference* of cached IME notification requests in `TextEventDispatcher`.
So, we need to refresh only the cache of IME notification requests in
`TextEventDispatcher`.
Differential Revision: https://phabricator.services.mozilla.com/D32821
--HG--
extra : moz-landing-system : lando
If Wayland is in use, then glXGetScreenDriver doesn't return the Mesa
driver name. There is a new API, eglGetDisplayDriverName, which was
added in Mesa 19 that works with Wayland.
Also expire the driver vendor is supplied for the proprietary NVIDIA and
ATI chipsets.
Differential Revision: https://phabricator.services.mozilla.com/D32631
Ship Wayland DMABuf protocol headers. This is a non-offical extension thus it's missing in stable wayland headers.
Differential Revision: https://phabricator.services.mozilla.com/D32632
--HG--
extra : moz-landing-system : lando
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This should be an idempotent patch. The way to come up with this patch has been:
* Run the first script attached to the bug and pipe it to xclip, then paste it
in color.rs
* Add the relevant #[derive] annotations and remove the color.mako.rs
definition.
* Reorder the values to match the ColorID definition, on which some widget
prefs and caching stuff relies on.
* Manually port some documentation from nsLookAndFeel.h
* Run `rg 'eColorID_' | cut -d : -f 1 | sort | uniq >files`
* Run the second script attached to the bug.
* Manually fix usage of `LAST_COLOR` (adding the `End` variant), and adding
casts to integer as needed.
* Add an static assert so that people remember to update the prefs, rather than
a comment on the definition :)
Differential Revision: https://phabricator.services.mozilla.com/D32610
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
- Follow Gtk and get theme button text color directly from "button" CSS node instead of "button label"
- Provide new -moz-gtk-buttonactivetext color for active/pressed button text color
- Replace ButtonText color with -moz-gtk-buttonactivetext when it's appropriate
Differential Revision: https://phabricator.services.mozilla.com/D30566
--HG--
extra : moz-landing-system : lando
Actually, all JNI Exceptions with `java.lang.OutOfMemoryError` call
`NS_ABORT_OOM(0)`. But `JNIEnv::NewString` in `StringParam::GetString` can know
OOM size when returning `nullptr`. So call `NS_ABORT_OOM` directly when
`NewString` is failure.
Differential Revision: https://phabricator.services.mozilla.com/D31026
--HG--
extra : moz-landing-system : lando
Recently we track and position all popups on Wayland which leads to
wrong placement when parent popup window is hidden.
In this patch we use plain gtk_window_move() for hidden popups and
we don't track them so they can't be used as a parent window.
Also implement nsWindow::HideWaylandPopupAndAllChildren() to clearly
hide a popup window with and its children windows.
Differential Revision: https://phabricator.services.mozilla.com/D31056
--HG--
extra : moz-landing-system : lando
This fix wrong rendering of radio and checkbox indicators in menus by
correcting the dimensions acording to used theme.
Differential Revision: https://phabricator.services.mozilla.com/D32316
--HG--
extra : moz-landing-system : lando
If OnKeysChanged was called after keyboard_handle_keymap, then our newly configured keymap would be immediately cleared again. In order to avoid such scenario, use only keyboard_handle_keymap on wayland.
Differential Revision: https://phabricator.services.mozilla.com/D32599
--HG--
extra : moz-landing-system : lando
Use standard Gtk/Gnome way to set Firefox Gtk theme. Gtk theme of web content can be still configured
by widget.content.allow-gtk-dark-theme and widget.content.gtk-theme-override.
Depends on D29823
Differential Revision: https://phabricator.services.mozilla.com/D30919
--HG--
extra : moz-landing-system : lando
We previously disabled system dark themes for Firefox chrome and content by gtk-application-prefer-dark-theme settings.
That option is no longer preferred by gnome project and was removed from tweaks tools. Theme makers are encouraged to use
a different name for the dark theme variants, like Adwaita-dark, Yaru-dark and so on. This option also does not
work when the GTK theme is missing the light variant completely.
To address that, this patch implements heuristics based on https://www.w3.org/TR/AERT/#color-contrast
to check if the system GTK theme has good contrast/visibility with default HTML colors
(white background and black text).
If widget.content.gtk-theme-override is empty and the system theme fails the test with gtk-application-prefer-dark-theme set to false, then Adwaita:light theme is used.
This patch was tested with some distro default light themes (Ambiance, Radiance, Yaru - Ubuntu, Arc - KDE, Menta - MATE)
and dark/light themes are recognized correctly.
Differential Revision: https://phabricator.services.mozilla.com/D29823
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
`GetInternalCommand()` is currently used only by `EditorCommand` and it
treats the additional parameter only when given command is `cmd_align`.
However, the value is complicated since `AlignCommand` allows both `CString`
value and `String` value. Therefore, `EditorCommand::DoCommandParams()` may
fail to solve `cmd_align` to a `Command` value without checking both of them.
Therefore, it must make sense that `GetInternalCommand()` take `nsCommandParams`
as optional argument and check it only when given command matches `cmd_align`.
Then, we don't need to waste unnecessary run-time cost.
Note that this bug has been hidden since `AlignCommand` class does not refer
the `Command` value but refers only `nsCommandParams`. However, the previous
patch makes `EditorCommand::GetParamType()` not allow `Command::DoNothing`.
Therefore, we need this follow-up fix now.
Differential Revision: https://phabricator.services.mozilla.com/D30501
--HG--
extra : moz-landing-system : lando
If `nsIControllerCommand::DoCommandParams()` is called without aParams or
`nsITransferable` pointer, this patch sets nullptr to `aTransferableParam` for
`DoCommandParam()`. This allows each implementation to choose ignore or
return error.
Differential Revision: https://phabricator.services.mozilla.com/D30500
--HG--
extra : moz-landing-system : lando
Only `MultiStateCommandBase::DoCommandParams()` allows `CString` param and
`String` param (the former is preferred). This patch makes
`EditorCommand::DoCommandParams()` aware of this case.
Differential Revision: https://phabricator.services.mozilla.com/D30499
--HG--
extra : moz-landing-system : lando
Most `EditorCommand` classes don't require additional params for executing
a command. All of them just calls their `DoCommand()` or returns same result.
So, we can create new virtual method,
`EditorCommand::DoCommandParam(Command aCommand, TextEditor& aTextEditor)`,
which just delegates to `DoCommand()`.
This patch adds some undeclared commands but which are handled by
`EditorCommand` subclasses, and changes `CommandInt` type from `int8_t` to
`uint8_t` since the count of `Command` items becomes over 128.
Differential Revision: https://phabricator.services.mozilla.com/D30495
--HG--
extra : moz-landing-system : lando
Profiling shows that we're spending a lot of time on startup inside
android.media.MediaCodecList.getCodecCount when GfxInfo::GetFeatureStatus calls
over to Java to determine whether hardware accelerated video encoding is
supported.
Looking at the Java stacks in the profile, Android is spending most of our time
creating a list of codecs. It doesn't look like there's a faster way to query
for hardware accelerated video support. So to speed this up we can cache the
value in the user's profile. We also store the OS version, which we can use to
detect when the OS is updated so we can invalidate the cache then.
Presumably an OS update is the only way a device can have its hardware acceleration
support status change.
With this change, the time we take figuring out the HW encode/decode status
goes from ~100ms on a cold run to ~0.01ms on a cache hit on my HD8 tablet.
Differential Revision: https://phabricator.services.mozilla.com/D31380
--HG--
extra : moz-landing-system : lando
Amend several test files for triggering eval() assertion through simpletest.js
Differential Revision: https://phabricator.services.mozilla.com/D30474
--HG--
extra : moz-landing-system : lando
nsITaskbarTabPreview has a notxpcom method, so it has always been
treated as builtinclass. This just makes it explicit.
The same thing is true for nsIPrintSettingsWin, but as far as I can
tell it is never actually used from JS, so I just removed the
scriptable tag.
Differential Revision: https://phabricator.services.mozilla.com/D30981
--HG--
extra : moz-landing-system : lando
If an XPIDL interface has a method or attribute that is [notxpcom],
then it is implicitly treated as [builtinclass], even if it is not
marked as such. For clarity, this patch goes through and marks every
place that relies on this behavior (aside from some test code).
Differential Revision: https://phabricator.services.mozilla.com/D30714
--HG--
extra : moz-landing-system : lando
ClientMarginHitTestPoint takes into account the fact that we want a minimum
of kResizableBorderMinSize pixels thickness around the window to trigger
resizing.
Differential Revision: https://phabricator.services.mozilla.com/D30427
--HG--
extra : moz-landing-system : lando
Support using the Google Play-provided FIDO2 API for Web Authentication.
FIDO U2F API support is being handled subsequently in Bug 1550625.
This patch uses the privileged APIs and thus will only work on Fennec Nightly, Beta, and Release builds.
Differential Revision: https://phabricator.services.mozilla.com/D1148
--HG--
extra : moz-landing-system : lando
The GECKOBUNDLE macros are useful to more than just a11y code, so let's move them into the jni package so that all jni consumers may drink of their sweet nectar.
Differential Revision: https://phabricator.services.mozilla.com/D30585
--HG--
extra : moz-landing-system : lando
In order to show all popups on Wayland we need to set popup parent runtime for popups which don't have
fixed parent. For instance popup menus (fired after right button mouse click) can be issued on top of another popup
and we need to follow that connection on Wayland.
We track all open (active) popups to:
- close all visible tooltip windows when we're going to open another tooltip
- close concurrent popup on the same level when a new one is about to open
- get latest active popup as a parent for a new tooltip windows
- get latest active popup as a parent for a new popup menu without fixed parent
Differential Revision: https://phabricator.services.mozilla.com/D29348
--HG--
extra : moz-landing-system : lando
As far as I've tested, `TextEditor` has the following structure patterns:
1. If it's for a non-empty `<input>` element, it has only one text node.
2. If it's for an empty `<input>` element, it has only bogus node.
3. If it's for a non-empty `<textarea>` element, it has a text node and
`moz-<br>` element. Additionally they are followed by `<scrollbar>` and
`<resizer>` elements.
4. If it's for an empty `<textarea>` element, it has a `moz-<br>` element
followed by `<scrollbar>` and `<resizer>` elements.
Additionally, `TextEditRules::WillInsert()` always removes bogus node if
there is. So, in the case #2, there is no children.
Fortunately, we don't support XUL addons anymore on Firefox. However, in
other products like Thunderbird, the tree may be changed as unexpected.
Therefore, we still need to keep checking the tree, but we can use the fast
path for `<textarea>` element too.
Differential Revision: https://phabricator.services.mozilla.com/D30012
--HG--
extra : moz-landing-system : lando
Expose the driver vendor information (applies to Linux only at this
moment) to crash report telemetry and about:support. This will be useful
when debugging issues to know specifically what driver is in use.
Also expose the monitor information for Linux. Part 1 provides an
implementation to get the monitor information on said platform.
Differential Revision: https://phabricator.services.mozilla.com/D29472
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
Expose the driver vendor information (applies to Linux only at this
moment) to crash report telemetry and about:support. This will be useful
when debugging issues to know specifically what driver is in use.
Also expose the monitor information for Linux. Part 1 provides an
implementation to get the monitor information on said platform.
Differential Revision: https://phabricator.services.mozilla.com/D29472
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
Expose the driver vendor information (applies to Linux only at this
moment) to crash report telemetry and about:support. This will be useful
when debugging issues to know specifically what driver is in use.
Also expose the monitor information for Linux. Part 1 provides an
implementation to get the monitor information on said platform.
Differential Revision: https://phabricator.services.mozilla.com/D29472
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
This prepares nsFrameLoader for replacing mBrowserParent and mBrowserBridgeChild
with a common interface by making special case code use a getter method instead
of direct access.
Differential Revision: https://phabricator.services.mozilla.com/D31437
--HG--
extra : source : 32eeee79d628dade8109454c636d5f8aaff0c93e
This prepares nsFrameLoader for replacing mBrowserParent and mBrowserBridgeChild
with a common interface by making special case code use a getter method instead
of direct access.
Differential Revision: https://phabricator.services.mozilla.com/D31437
--HG--
extra : rebase_source : a3493579481b7b79086c34486b7342783fd68070
extra : histedit_source : d4a2909d13575822d36611879d2e14211ef2cf3a
This driver version is known to have busg which cause the output of green
frames from the decoder, and to cause BSODs.
Differential Revision: https://phabricator.services.mozilla.com/D29603
--HG--
extra : moz-landing-system : lando
This patch makes widget use `mozilla::PresShell` directly rather than via
`nsIPresShell` and changes some pure virtual methods of `nsIPresShell` which
called by widget to `mozilla::PresShell`'s non-virtual methods.
Differential Revision: https://phabricator.services.mozilla.com/D29112
--HG--
extra : moz-landing-system : lando
The previous commit removed the dependence on the discriminant value, so we
don't need to keep discriminants different from text-align anymore.
Differential Revision: https://phabricator.services.mozilla.com/D29361
--HG--
extra : moz-landing-system : lando
Send tasks to dispatch our other wayland event queues from their respective threads whenever we service the GTK main event loop.
Differential Revision: https://phabricator.services.mozilla.com/D28819
--HG--
extra : moz-landing-system : lando
Now, we don't have any utility method to get `Command` value for XUL command
name. This patch creates it into `mozilla` namespace.
Differential Revision: https://phabricator.services.mozilla.com/D29173
--HG--
extra : moz-landing-system : lando
If I remember correctly, `enum class` was not allowed when I added
`enum Command`. Now, we can make it `enum class` for better type check at
compile time.
Differential Revision: https://phabricator.services.mozilla.com/D29169
--HG--
extra : moz-landing-system : lando
`CapturingContentInfo` struct is used only in `PresShell.cpp` so that we can
make it a private struct of `PresShell` if we move all users of them,
i.e., API to access them, from `nsIPresShell` to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D29111
--HG--
extra : moz-landing-system : lando
This override has no effect in CoreAnimation-backed windows. The upcoming
patches will implement an alternative approach.
Differential Revision: https://phabricator.services.mozilla.com/D22644
--HG--
extra : moz-landing-system : lando
Rounded bottom corners have been the default since 10.7.
We still have square corners on windows without titlebars, such as the address
bar autocomplete dropdown, or the reftest window.
Differential Revision: https://phabricator.services.mozilla.com/D22643
--HG--
extra : moz-landing-system : lando
The synchronous paint was only needed a long time ago when we were calling this
method during drawRect. We're not doing that any more, we usually call it from
viewWillDraw now. But even at the time, forcing a synchronous paint *within*
a paint was extremely sketchy, so best just to remove the code.
Differential Revision: https://phabricator.services.mozilla.com/D22642
--HG--
extra : moz-landing-system : lando
The iframe test runs on an cross-docgroup iframe, even though chrome JS can
observe it in this test.
This test is relying on the getBoundingClientRect() call below in order to flush
the parent document layout as well, but that's going to stop happening (see the
bug and patch).
Differential Revision: https://phabricator.services.mozilla.com/D28302
This override has no effect in CoreAnimation-backed windows. The upcoming
patches will implement an alternative approach.
Differential Revision: https://phabricator.services.mozilla.com/D22644
--HG--
extra : moz-landing-system : lando
The synchronous paint was only needed a long time ago when we were calling this
method during drawRect. We're not doing that any more, we usually call it from
viewWillDraw now. But even at the time, forcing a synchronous paint *within*
a paint was extremely sketchy, so best just to remove the code.
Differential Revision: https://phabricator.services.mozilla.com/D22642
--HG--
extra : moz-landing-system : lando
When we draw on HiDPI display on Linux we scale the widget. On Wayland/HiDPI displays allow to set cairo_surface_set_device_scale() to draw
hi-res widgets by moz_gtk_widget_paint().
Depends on D28466
Differential Revision: https://phabricator.services.mozilla.com/D28467
--HG--
extra : moz-landing-system : lando
Call gtk_style_context_set_scale() on styles created by WidgetStyleCache module on Gtk 3.20+
Also modify moz_gtk_widget_paint_* routines to pass the scale info to CreateStyleContext()
from WidgetStyleCache.
Differential Revision: https://phabricator.services.mozilla.com/D28466
--HG--
extra : moz-landing-system : lando
This patch moves remaining public `enum` of `nsIPresShell` to `mozilla`
namespace in `mozilla/PresShellForwards.h` and make them `enum class`es.
Additionally, some methods which use the moving `enum`s from `nsIPresShell`
to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D28607
--HG--
extra : moz-landing-system : lando
Wayland protocol allows to have only one popup window attached to a parent widget.
Recently we use a toplevel window widget as parent for all popups.
That means a second level menu (like File -> New Container Tab)
is not displayed as both ("File" and "New Container Tab" menus)
have the same parent widget.
As a solution allow to get the actual parent run-time and set that
when we open the window on toolkit level.
This patch covers menu widgets in the same frame hierarchy.
Differential Revision: https://phabricator.services.mozilla.com/D26112
--HG--
extra : moz-landing-system : lando
shindli
Kris Maglione
Martin Stransky
Gurzau Raul
Cosmin Sabou
Markus Stange
Gerald Squelart
sotaro
Andreea Pavel
Coroiu Cristina
Nicholas Nethercote
Ryan Hunt
Tarek Ziadé
arthur.iakab
myfreeweb
Masatoshi Kimura
Razvan Maries
Oana Pop Rus
Daniel Varga
Kartikaya Gupta
Christoph Walcher
Jeff Gilbert
Henri Sivonen
Noemi Erli
Peter Van der Beken
Boris Zbarsky
Brindusan Cristian
Sylvestre Ledru
Dorel Luca
Sebastian Hengst
Mihai Alexandru Michis
Nicolas Silva
Jonathan Watt
Andrew Osmond
Bogdan Tara
Neil Deakin
Masayuki Nakano
Emilio Cobos Álvarez
Edgar Chen
Jan Horak
Tom Ritter
Valentin Gosu
Jean-Yves Avenard
Makoto Kato
Kenny Levinsen
Joel Maher
Ciure Andrei
Chris Pearce
Jonas Allmann
Andrew McCreight
Christina
Mike Conley
J.C. Jones
Lee Salzman
alwu
Thomas Nguyen
Eitan Isaacson
Sebastian Streich