MANUAL PUSH: Backout and comment change that don't require a review and are somewhat time-critical: the backout fixes breakage in some local build scenarios.
--HG--
extra : rebase_source : 5230000ce88395794c272f0133e09979c70d526d
extra : amend_source : df014e518d27480c5b149acb8acaa0433565d483
The source of the trouble is our setContents override, which makes sure the window's
content view is the bottommost view in the window, and its interaction with a change
in behavior on 10.14, where windows that return YES from _wantsFloatingTitlebar will
contain an additional NSView for the window background. Our setContents override
moves the content view behind that window background view, which covers it with a
solid gray color.
--HG--
extra : amend_source : cd11d5c805de7054c3dfa3a1d5ae0f504f07116d
This also moves the MaybeScheduleUnsuspendAsyncCATransactions() call to the end
of HandleMainThreadCATransaction() so that we can't get re-suspended from within
WillPaintWindow().
Differential Revision: https://phabricator.services.mozilla.com/D42763
--HG--
extra : moz-landing-system : lando
This can be verified by starting Firefox with the environment variables
CA_LAYER_SURFACE=0 CA_COLOR_OPAQUE=1
Transparent parts of the window will be red, and opaque parts will be green.
With this patch, the main browser window will be opaque except for the vibrant
areas, i.e. the tab bar and any open sidebars, which will be transparent.
Full screen video will be opaque.
Differential Revision: https://phabricator.services.mozilla.com/D40555
--HG--
extra : moz-landing-system : lando
updateLayer expects some objects to be non-null which are only initialized when the pref is set.
But in builds that were compiled with the 10.14 SDK, all NSViews are layer-backed by default, so
wantspdateLayer gets called, and returning YES from that unconditionally will cause updateLayer
to be called.
Differential Revision: https://phabricator.services.mozilla.com/D42333
--HG--
extra : amend_source : a7a1f7ecba9418e3bf5464bca90ba655002bc637
Without this, in windows with title bars, such as the bookmark library window,
the title bar and the content would update at different times.
The title bar paint is done as part of a main thread CoreAnimation transaction.
However, by default, we don't get notified of all main thread CA transactions;
our only notification mechanism is the updateLayer handler on the PixelHostingView,
and that handler is only invoked (the layer is only displayed) if the layer has
been marked as needing display. And by default, window focus changes do not mark
random views' backing layers as needing display. Usually, what this means is that
the window will be painted twice: Once in the main thread transaction, and then
another time on the compositor thread once Gecko has noticed a state change and
triggered its own composite in response. (Often, Gecko's compositor-side paint
will actually happen *before* the main thread paint, because the main thread is
often busy with repainting the system menu bar during window focus changes.)
Such non-atomic window repaints look glitchy.
Calling SuspendAsyncCATransactions will result in a call to updateLayer in the
upcoming CoreAnimation transaction and lets us update the entire window in one
atomic paint, and it will avoid updating the window early if the compositor
thread gets ahead of the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D38759
--HG--
extra : moz-landing-system : lando
Window overlay drawing was added as a workaround for the following:
When our NSOpenGLContext covered the entire window, it would cover the titlebar
contents and hide the window buttons and the title string. It would also not
get anti-aliased rounded corner clipping.
In windows that use CoreAnimation layers for the window frame, this is no longer
a problem, because the CoreAnimation layer tree takes care of these effects:
It applies rounded corner clipping to the window content layers, it puts the
window buttons on top, and it also puts the title string on top if it is shown.
So when we're using CoreAnimation, the existing code needs to be deactivated,
otherwise we'd draw those things twice.
Differential Revision: https://phabricator.services.mozilla.com/D38760
--HG--
extra : moz-landing-system : lando
Now CoreAnimation supports all rendering paths.
The BasicCompositor OMTC path is used when hardware acceleration is disabled,
for example in safe mode or when the user manually disabled it.
Differential Revision: https://phabricator.services.mozilla.com/D38758
--HG--
extra : moz-landing-system : lando
This makes windows that render using CompositorOGL or WebRender show content.
Differential Revision: https://phabricator.services.mozilla.com/D40517
--HG--
extra : moz-landing-system : lando
This makes context menus work. Regular windows are still blank at this point.
This introduces a visual regression on 10.9: context menus and panels now no
longer have a shadow. Only 10.10 and above support shadows on transparent windows
that use CoreAnimation; 10.9 is not able to obtain the shadow shape on those
types of windows.
I think this is an acceptable regression to take. We want to use CoreAnimation
for all window types because it simplifies the code (no need to handle two
paths) and because it avoids expensive mode switches if we realize too late
that a window we just opened is supposed to use CoreAnimation.
Differential Revision: https://phabricator.services.mozilla.com/D40516
--HG--
extra : moz-landing-system : lando
This makes mPixelHostingView layer-backed, and that layer will be empty.
This patch also causes all windows (including context menus, tooltips, arrow
panels etc.) to use CoreAnimation layers for the window frame. This is achieved
by calling setWantsLayer:YES on every window's content view.
After this changeset, all windows will still be empty.
Differential Revision: https://phabricator.services.mozilla.com/D38755
--HG--
extra : moz-landing-system : lando
This patch leaves you with empty windows everywhere. We will build the new
rendering paths from the ground up in the upcoming patches.
Differential Revision: https://phabricator.services.mozilla.com/D38754
--HG--
extra : moz-landing-system : lando
Unlike what the old comment in its drawRect method says, this isn't actually
dependent on the NSFullSizeContentViewWindowMask. Any window that uses
CoreAnimation layers for its window frame will apply these effects automatically.
Differential Revision: https://phabricator.services.mozilla.com/D38753
--HG--
extra : moz-landing-system : lando
We always use OMTC when using OpenGL. We also currently always use OpenGL when using OMTC, but that's about to change.
Differential Revision: https://phabricator.services.mozilla.com/D38752
--HG--
extra : moz-landing-system : lando
BasicLayers is main thread drawing. BasicCompositor is compositor-thread drawing.
Differential Revision: https://phabricator.services.mozilla.com/D38749
--HG--
extra : moz-landing-system : lando
Investigation showed that on this platform the texture unit state becomes
corrupted whenever we set the non-identity swizzling (getting garbage from textureSize()).
Given no easy workaround, we disable swizzling for this GPU family on Mac, for now.
Differential Revision: https://phabricator.services.mozilla.com/D41274
--HG--
extra : moz-landing-system : lando
Use addGlobalMonitorForEventsMatchingMask instead of CGEventTapCreate to monitor for mouse clicks outside of the application while context menus are displayed.
Using addGlobalMonitorForEventsMatchingMask prevents the display of the privacy "Keystroke Receiving" dialog when listening for mouse clicks.
Differential Revision: https://phabricator.services.mozilla.com/D39973
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
While there, transform the MOZ_ASSERTs into static_asserts, so that
discrepancies are caught at build time rather than runtime.
Differential Revision: https://phabricator.services.mozilla.com/D38165
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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 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 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 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
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
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
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
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
Moved mozilla::WidgetMosueEventBase::buttonType in MouseEvents.h to mozilla::MouseButton in EventForwards.h, and mozilla::WidgetMouseEventBase::buttonsFlag to mozilla::MouseButtonsFlag so that any referer in header files do not need to include MouseEvents.h only for referring them. Instead, they just need to include EventForwards.h. Now when MouseEvents.h is changed, the rebuild speed becomes faster.
Differential Revision: https://phabricator.services.mozilla.com/D25325
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::inputSource to WidgetMouseEventBase::mInputSource
Differential Revision: https://phabricator.services.mozilla.com/D25322
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::pressure to WidgetMouseEventBase::mPressure
Differential Revision: https://phabricator.services.mozilla.com/D25314
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::button to WidgetMouseEventBase::mButton.
Differential Revision: https://phabricator.services.mozilla.com/D25309
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::buttons to WidgetMouseEventBase::mButtons
Differential Revision: https://phabricator.services.mozilla.com/D25297
--HG--
extra : moz-landing-system : lando
This patch makes `nsViewManager::GetPresShell()` and
`nsIWidgetListener::GetPresShell()` (overridden by `nsView` and
`nsWebShellWindow::WidgetListenerDelegate`) return `mozilla::PresShell*`.
Additionally, makes `nsWebShellWindow::GetPresShell()` also return
`mozilla::PresShell()`.
Differential Revision: https://phabricator.services.mozilla.com/D26454
--HG--
extra : moz-landing-system : lando
Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
Don't swizzle the terminate method in process types that don't initialize the nsApplication.
Differential Revision: https://phabricator.services.mozilla.com/D26397
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
`nsChildView::GetEditorView()` is called by `TextInputHandlerBase::GetWindowLevel()`
which is called when Cocoa requests window level of focused widget.
It currently gets widget including focused element (e.g., it may be in a XUL
`<panel>`) with `eQueryTextContent` event. However, it requires only the widget
(i.e., when a XUL `<panel>` has focused element, the widget for the panel).
Therefore, it does not require to flush the layout.
However, on macOS, `ContentEventHandler` always flushes layout even with
`eQueryContentState` which does not require any layout information. Whether
it requires flushing layout or not is considered with
`WidgetQueryContentEvent::mNeedsToFlushLayout` but this is set to false only
when `IMEContentObserver` notifies widget (and IME) of focus set. At this
time, only on macOS, IME caches the layout information, for example, the
character coordinates, but we don't have a way to update it. This is the reason
why we always flush layout on macOS.
Unfortunately, when a menu popup frame is created, widget for the popup is
created synchronously. Then, Cocoa retrieves window level of the widget including
focused element. But this is unsafe to flush the layout. So, we need to stop
flushing layout in this case.
Therefore, this patch moves the `#ifdef` from `TextEvents.h` to
`IMEContentObserver.cpp`, then, makes `nsChildView::GetEditorView()` use
`eQueryContentState` which is the simplest query content event, and finally,
sets `mNeedsToFlushLayout` to `false`.
Differential Revision: https://phabricator.services.mozilla.com/D25912
--HG--
extra : moz-landing-system : lando
On Mac, don't attempt to save print settings after the user cancels out of the print dialog.
Differential Revision: https://phabricator.services.mozilla.com/D23889
--HG--
extra : moz-landing-system : lando
Load the saved printer-specific settings prefs before displaying the print dialog.
PrintSettings received from sandboxed content processes do not include the printer name because access to the printer server is blocked by sandboxing.
Differential Revision: https://phabricator.services.mozilla.com/D23888
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
--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
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
Changes updateTouchBarInput to a batch-updating updateTouchBarInputs.
Also adds a check for a cached localized title to getTouchBarInput().
Differential Revision: https://phabricator.services.mozilla.com/D20956
--HG--
extra : moz-landing-system : lando
Based on the implementation and issues on prefers-reduced-motion, it
seems we have the same issue on the dark mode.
In child processes on MacOSX we don't spin native event loop at all.
Without native event loops, the global preference returned from
`SystemWantsDarkTheme()` doesn't return up-to-date value when the system
setting changed for some reasons.
To workaround this we call `SystemWantsDarkTheme()` only on the parent
process which spins native event loop or when it's the initial query on
the child process. And we give the up-to-date value to the child process
via an IPC call just like other cached values do.
Differential Revision: https://phabricator.services.mozilla.com/D21303
--HG--
extra : moz-landing-system : lando
`TextInputHandler::HandleCommand()` dispatches `Tab` key events only when
it receives `insertTab:` or `intertBacktab:` command which are caused by
actual `Tab` key press.
However, these commands could be generated by IME or the system shortcut
keys are customized oddly.
This patch makes the method support such situation with dispatching fake
`keydown` and `keypress` events to emulate `Tab` key press for
mainly focus navigation.
Differential Revision: https://phabricator.services.mozilla.com/D20804
--HG--
extra : moz-landing-system : lando
Currently, when IME sends a command with committing composition,
TextInputHandler::HandleCommand() dispatches a *fake* `keypress` event
for making default event handler (e.g., focused editor) handle the
event. However, we stopped dispatching `keypress` events for
non-printable keys. Therefore, web apps cannot do that like us.
On macOS, simple conversion IMEs like Korean 2-set IME, behave
differently if active application is changed. E.g., on Safari,
some of them may never use composition string, but not so on
Chrome and Firefox. So, this is what the case we need to emulate
Safari's behavior.
Dispatching a fake `keydown` event for this purpose does **not**
conform to UI Events because `keydown` events should notify web
apps of **physical** key state changes. However, Chrome dispatches
fake `keydown` events intentionally. Therefore, we should follow
this hacky behavior for user experience.
Differential Revision: https://phabricator.services.mozilla.com/D20644
--HG--
extra : moz-landing-system : lando
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--HG--
extra : moz-landing-system : lando
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--HG--
extra : moz-landing-system : lando
Splitting part of OGLShaderProgram.h out into OGLShaderConfig.h makes it
easier to keep GLContext.h included in OGLShaderProgram.h for inlining
purposes.
Differential Revision: https://phabricator.services.mozilla.com/D20017
--HG--
extra : moz-landing-system : lando
widget/cocoa/nsChildView.mm:249:6 [-Wmissing-prototypes] no previous prototype for function 'EnsureLogInitialized'
Depends on D20087
Differential Revision: https://phabricator.services.mozilla.com/D20088
--HG--
extra : moz-landing-system : lando
widget/cocoa/nsChildView.mm:1932:21 [-Wmissing-prototypes] no previous prototype for function 'TextureSizeForSize'
widget/cocoa/nsCocoaUtils.mm:351:6 [-Wmissing-prototypes] no previous prototype for function 'data_ss_release_callback'
Differential Revision: https://phabricator.services.mozilla.com/D20087
--HG--
extra : moz-landing-system : lando
The only caller wants CSS pixels, no need to go back and forth.
This is the last dependency on the pres context, I think, from the style system
font code.
Differential Revision: https://phabricator.services.mozilla.com/D19147
This is a clearer implementation that achieves the same thing.
Moreover, disabling the clearing by overriding drawRect wouldn't work in
CoreAnimation windows because in CoreAnimation windows, the clearing happens
through a property of the NSVisualEffectView's CALayer, and not through the
view's drawRect implementation - drawRect probably isn't even called in that
context.
Differential Revision: https://phabricator.services.mozilla.com/D19601
--HG--
extra : moz-landing-system : lando
This has two advantages:
- The drawing will now correctly be placed "on top" of the vibrancy views.
- We can turn this new view into a layer-hosting view. Layer-hosting views are
supposed to be leaf NSViews; they shouldn't have any children.
Differential Revision: https://phabricator.services.mozilla.com/D19600
--HG--
extra : moz-landing-system : lando
Otherwise, any views inside the contentView are imbued with a vibrant effect, and
even non-NSVisualEffectView NSViews subtract from the vibrant region of any actual
vibrant views they overlap. This would cause the PixelHostingView to 'erase' the
blue context menu item highlighting.
This behavior is documented on NSVisualEffectView:
> It is recommended that you enable vibrancy only in the leaf views of your view
> hierarchy. Subviews inherit the vibrancy of their parent. Once enabled in a
> parent view, a subview cannot turn off vibrancy. As a result, enabling
> vibrancy in a parent view can lead to subviews that look incorrect if they are
> not designed to take advantage of the vibrancy effect.
Differential Revision: https://phabricator.services.mozilla.com/D19599
--HG--
extra : moz-landing-system : lando
NSView hierarchy before:
- window contentView
- ChildView
- NonDraggableView 1
- NonDraggableView 2
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
NSView hierarchy after:
- window contentView
- ChildView
- ViewRegionContainerView
- NonDraggableView 1
- NonDraggableView 2
- ViewRegionContainerView
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
This allows us to give those container views a new sibling view which stays
fixed in z-order with respect to the NSViews that get created by
mNonDraggableRegion and mVibrancyManager. More specifically, I'm going to add a
view for the drawing of our ChildView ("PixelHostingView") which is going to be
a direct child of the Gecko "ChildView" and a sibling of the
ViewRegionContainerViews; the PixelHostingView needs to always stay on top of
the vibrancy views.
Without the wrapper around the vibrancy views, whenever the vibrant region
changes, a vibrant view would be placed on top of the PixelHostingView and the
order would be wrong.
Differential Revision: https://phabricator.services.mozilla.com/D19598
--HG--
extra : moz-landing-system : lando
This was added in bug 476393 in order to work around a problem with the Java plug-in.
We no longer support that plug-in.
The comment also mentions NSTexturedBackgroundWindowMask which we stopped using in bug 1335191.
Differential Revision: https://phabricator.services.mozilla.com/D19558
--HG--
extra : moz-landing-system : lando
This method could only return something non-null in embedding situations,
in which our ChildView was a subview of somebody else's NSView that conforms
to the mozView protocol. Such a situation hasn't existed for about 10 years.
Differential Revision: https://phabricator.services.mozilla.com/D19555
--HG--
extra : moz-landing-system : lando
Markus Stange
Sebastian Hengst
Sylvestre Ledru
harry
Dzmitry Malyshau
Haik Aftandilian
Nicholas Nethercote
Thomas Nguyen
Ciure Andrei
Mike Hommey
Xidorn Quan
Brendan Dahl
Mihai Alexandru Michis
Andreea Pavel
shindli
Coroiu Cristina
Tarek Ziadé
Razvan Maries
Oana Pop Rus
Gurzau Raul
Kartikaya Gupta
Christoph Walcher
Jeff Gilbert
Boris Zbarsky
Brindusan Cristian
Jonathan Watt
Emilio Cobos Álvarez
Andrew Osmond
Jean-Yves Avenard
arthur.iakab
Christina
Masayuki Nakano
Daniel Varga
Noemi Erli
Srujana Peddinti
Michael Froman
Andrew McCreight
Csoregi Natalia
Narcis Beleuzu
Cosmin Sabou
Josh Aas
Dorel Luca
Harry Twyford
Brad Werth
Andrew Comminos
Boris Chiou
Alex Gaynor
Chris Peterson
Stephen A Pohl
Eitan Isaacson