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
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
Markus Stange
Jan Horak
harry
Sylvestre Ledru
sotaro
Mihai Alexandru Michis
Jan Andre Ikenmeyer
Nicholas Nethercote
Brendan Dahl
Barret Rennie
Mike Conley
Masayuki Nakano
Jonathan Kingston
Victor Porof
Aaron Klotz
Razvan Maries
Csoregi Natalia
Oana Pop Rus
Rob Wu
Makoto Kato
arthur.iakab
Sebastian Streich
Narcis Beleuzu
Henri Sivonen
Andreea Pavel
Martin Stransky
shindli
Kris Maglione
Gurzau Raul
Cosmin Sabou
Gerald Squelart
Coroiu Cristina
Ryan Hunt
Tarek Ziadé
myfreeweb
Masatoshi Kimura
Daniel Varga
Kartikaya Gupta
Christoph Walcher
Jeff Gilbert
Noemi Erli
Peter Van der Beken
Boris Zbarsky
Brindusan Cristian
Dorel Luca
Sebastian Hengst
Nicolas Silva
Jonathan Watt
Andrew Osmond
Bogdan Tara
Neil Deakin
Emilio Cobos Álvarez
Edgar Chen
Tom Ritter
Valentin Gosu
Jean-Yves Avenard
Kenny Levinsen
Joel Maher
Ciure Andrei
Chris Pearce
Jonas Allmann
Andrew McCreight
Christina
J.C. Jones
Lee Salzman
alwu
Thomas Nguyen