Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
Make it return a margin from client area to window area, and add an
explicit function to get the size difference.
No behavior change.
Depends on D166428
Differential Revision: https://phabricator.services.mozilla.com/D166431
This changes the behavior in a few ways:
- the 'active' notification is now only fired when a new user event has been received by Firefox, rather than by any application on the entire system.
- the 'active' notification will fire immediately when Firefox receives a new event. Before the patch is was fired within 5s of the user returning on some plateforms (eg. Mac) and immediately on some other platforms that already called ResetIdleTimeout (windows, gtk, android). I'm not sure if these existing calls to ResetIdleTimeout are really needed, nor if they add significant overhead.
- when an idle observer has been notified of 'idle', it won't be notified again until Firefox receives events. Before the patch, if the user used other applications while Firefox was in the background, we would keep sending active and idle notifications to our idle observers. This behavior was probably initially intended when the nsUserIdleService was introduced to support the use case of instant messaging clients, but doesn't seem to match the expectations of the existing consumers of the service.
Differential Revision: https://phabricator.services.mozilla.com/D166306
This adds context to `CloseAlert()` such that explicitly closing the notification e.g. `notification.close()` can be differentiated from a tab or window implicitly closing the notification. This is necessary as we want notifications to persist after a tab or window is closed for Windows.
This change in behavior is necessary to match user expectations. Users expect notifications to persist in the system tray and do not expect notifications to be lost due to a tab being closed. The content of the message is more important than the interaction in that lens. This change is also necessary for parity with Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D161024
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
All implementors currently simply resolve the promise right away, using
crutch code. Asynchronous usage will be added in the changeset that follows.
Differential Revision: https://phabricator.services.mozilla.com/D163508
This is a modified version of Haik's patch D114133. It aims to fix the
issues that cause our macOS native fullscreen tests to fail. To accomplish
this, it does these things:
1) It clarifies that emulated fullscreen and native fullscreen are
distinct end states. You can transition to fullscreen using either
method, but from there you can only leave fullscreen. In other words you
can't go directly from emulated fullscreen to native fullscreen nor the
other way.
2) It captures the NSWindow delegate methods associated with a native
fullscreen transition, and uses these to trigger and update the
transition in and out of native fullscreen. It is still possible to
programmatically trigger a native fullscreen transition using
DoMakeFullscreen.
3) It correclty handles requests to change fullscreen while a fullscreen
transition is still in progress. If a contrary change is requested during
transition, then the transition is marked for reversion when it's
complete.
Notably, it does *not* attempt to send any kind of event when the native
fullscreen transition is complete. There is no event-based method for the
browser (or the test harness) to know when the transition is complete. The
test harness will typically check for the sizemode events, which are sent
when the fullscreen transition begins. If the test harness quickly toggles
fullscreen off again, then the transition will be marked for reversion,
and the test harness will detect the the end of fullscreen as soon as the
reverting transition begins.
Callers could get the nsCocoaWindow into the wrong state by requesting
native fullscreen, and then while the transition is happening, requesting
an exit of fullscreen and then requesting emulated fullscreen. This would
be really hard for a user to accomplish, and our test harness should be
waiting for sizemode events after each transition and so it won't request
fullscreen in rapid succession like that.
Differential Revision: https://phabricator.services.mozilla.com/D160097
Nowadays, only the frontend code should pre-populate the nsIPrintSettings
objects with saved prefs (before passing them those objects to platform code).
We removed the InitPrintSettingsFromPrefs calls from the Windows and Linux
native dialog code, but apparently not the macOS code.
Differential Revision: https://phabricator.services.mozilla.com/D164709
Note: NSPagesAcross/NSPagesDown is internal API to Apple and is basically
unknown to the Internet. I discovered it by digging through printing structs in
a debugger while trying to find out how the pages-per-sheet information was
being communicated internally in Cocoa. However, after finding it, I see Google
knows about a grand total of 18 pages on the Internet that mention it, all as
part of debug info dumps. That's still helpful though, since it shows that
these two dictionary entries have been in use since at least 2008, giving some
confidence about backwards compatibility and that it will likely remain in use.
Related to these dictionary keys, Apple's official documentation claims that
there are similarly named keys called NSPrintPagesAcross/NSPrintPagesDown:
https://developer.apple.com/documentation/appkit/nsprintpagesacrosshttps://developer.apple.com/documentation/appkit/nsprintpagesdown
However, I couldn't get those to work, either to read values or to set values.
The references I could find to them on the Internet were in debug output and
people also stating they couldn't get them to work. I have to wonder if someone
at Apple changed the names at some point and forgot to update the
documentation?!
Finally, note that NSPrintPagesPerSheet is long deprecated and nowadays just
has a dummy value of "1" hardcoded.
https://developer.apple.com/documentation/appkit/nsprintpagespersheet
Differential Revision: https://phabricator.services.mozilla.com/D164317
Note: NSPagesAcross/NSPagesDown is internal API to Apple and is basically
unknown to the Internet. I discovered it by digging through printing structs in
a debugger while trying to find out how the pages-per-sheet information was
being communicated internally in Cocoa. However, after finding it, I see Google
knows about a grand total of 18 pages on the Internet that mention it, all as
part of debug info dumps. That's still helpful though, since it shows that
these two dictionary entries have been in use since at least 2008, giving some
confidence about backwards compatibility and that it will likely remain in use.
Related to these dictionary keys, Apple's official documentation claims that
there are similarly named keys called NSPrintPagesAcross/NSPrintPagesDown:
https://developer.apple.com/documentation/appkit/nsprintpagesacrosshttps://developer.apple.com/documentation/appkit/nsprintpagesdown
However, I couldn't get those to work, either to read values or to set values.
The references I could find to them on the Internet were in debug output and
people also stating they couldn't get them to work. I have to wonder if someone
at Apple changed the names at some point and forgot to update the
documentation?!
Finally, note that NSPrintPagesPerSheet is long deprecated and nowadays just
has a dummy value of "1" hardcoded.
https://developer.apple.com/documentation/appkit/nsprintpagespersheet
Differential Revision: https://phabricator.services.mozilla.com/D164317
Bug 1796849 implemented proper non-native tooltips so that we can draw
them in mismatched themes in GTK. That uses the InfoBackground /
InfoText color pair, which is the right color pair.
However on macOS InfoBackground didn't have dark-mode support (while
InfoText did), causing contrast issues.
Differential Revision: https://phabricator.services.mozilla.com/D163022
And hide internal but used values. System fonts are not exposed in the
computed style so this should be fine.
If we need the old values for some obscure reason, it's trivial to alias
them to e.g., menu or so.
Differential Revision: https://phabricator.services.mozilla.com/D163269
And hide internal but used values. System fonts are not exposed in the
computed style so this should be fine.
If we need the old values for some obscure reason, it's trivial to alias
them to e.g., menu or so.
Differential Revision: https://phabricator.services.mozilla.com/D163269
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
WebRender is a mature feature. We should start blocking it on known bad
devices over allowlisting known good devices. This may enable WebRender
in a few more obscure places than we shipped before.
Differential Revision: https://phabricator.services.mozilla.com/D160120
WebRender is a mature feature. We should start blocking it on known bad
devices over allowlisting known good devices. This may enable WebRender
in a few more obscure places than we shipped before.
Differential Revision: https://phabricator.services.mozilla.com/D160120
Ensure that when we evaluate the downloadable blocklist, we actually
only use the downloadable blocklist. We should not include any platform
specific checks in these prefs, as it causes confusion about why the
prefs were set in the first place. Allowlisted features should be
ignored when evaluating the downloadable blocklist; if we wish to
override the ALLOW/ALLOW_QUALIFIED/DENIED statuses, we should use OK or
BLOCKED_DEVICE or similar instead.
This caused allowlisted features (like WebRender) to be taken away from
users in the most recent nightly.
Differential Revision: https://phabricator.services.mozilla.com/D160408
Ensure that when we evaluate the downloadable blocklist, we actually
only use the downloadable blocklist. We should not include any platform
specific checks in these prefs, as it causes confusion about why the
prefs were set in the first place. Allowlisted features should be
ignored when evaluating the downloadable blocklist; if we wish to
override the ALLOW/ALLOW_QUALIFIED/DENIED statuses, we should use OK or
BLOCKED_DEVICE or similar instead.
This caused allowlisted features (like WebRender) to be taken away from
users in the most recent nightly.
Differential Revision: https://phabricator.services.mozilla.com/D160408
The color picker currently appears in a "default" location upon opening, which seems to be for my machines the bottom left of the screen or another screen entirely depending on where my Firefox instance was opened. It seems like the best way to fix this is to actually create the color picker where you have clicked for it. Since `nsColorPanel` ultimately inherits from `nsWindow`, we can do this while opening by calling our `setFrameOrigin` method with the current pointer location.
Differential Revision: https://phabricator.services.mozilla.com/D157710
The XUL behavior in nsBox.cpp is fairly different to what the non-XUL
layout code paths do. In particular, canOverride=false means that the
min-{width,height} properties cannot go under the min widget size of the
widget, but that doesn't mean that intrinsic sizes don't affect the
final size of the widget.
This is very visible if you turn on flex emulation on Windows or macOS,
where the toolbar has an appearance that returns
width=0,height=N,canOverride=false.
With flex emulation we'd collapse the item to be zero-width, which is
not good at all.
The good thing is that this is no longer exposed to the web
(non-native-theme always returns canOverride=true), and our front-end
code doesn't seem to rely on this, so we can just remove support for
canOverride=false.
Differential Revision: https://phabricator.services.mozilla.com/D158608
There are only 3 places where nsMemory.h is still needed (image/RasterImage.cpp,
gfx/thebes/gfxFT2FontList.cpp, and nsMemory.cpp). Remove the rest.
Differential Revision: https://phabricator.services.mozilla.com/D158213
Deletion of mutation observers from a list resulted in O(n^2) behavior and could lead to massive freezes.
This is resolved by using a LinkedList instead, reducing complexity to O(n).
A safely iterable doubly linked list was implemented based on `mozilla::DoublyLinkedList`,
allowing to insert and remove elements while iterating the list.
Due to the nature of `mozilla::DoublyLinkedList`, every Mutation Observer now inherits `mozilla::DoublyLinkedListElement<T>`.
This implies that a Mutation Observer can only be part of one DoublyLinkedList.
This conflicts with some Mutation Observers, which are being added to multiple `nsINode`s.
To continue supporting this, new MutationObserver base classes `nsMultiMutationObserver` and `nsStubMultiMutationObserver` are introduced,
which create `MutationObserverWrapper` objects each time they are added to a `nsINode`.
The wrapper objects forward every call to the actual observer.
Differential Revision: https://phabricator.services.mozilla.com/D157031
Unfortunately this test doesn't run as expected on our CI since macs on our CI
are running normal DPI mode.
I tested this test works properly on my macbook, it fails without the fix in the
previous commit and it passes with the fix.
Differential Revision: https://phabricator.services.mozilla.com/D153688
This matches what Linux and macOS do, and that allows the fix for bug 1782623
to work on Windows for unstyled selects.
This also simplifies the CSS (though it adds a new system color which is a bit
more annoying). I filed https://github.com/w3c/csswg-drafts/issues/7561 to
propose adding a more generic way to do this in the future (not just for
Firefox).
Differential Revision: https://phabricator.services.mozilla.com/D153549
Use a larger stack size on macOS 13 for the Wifi monitor thread to accommodate Core WLAN code allocating 217K+ on the stack.
Differential Revision: https://phabricator.services.mozilla.com/D152555
Just like it manages content, so that we stop chrome animations and such
in hidden or fully-occluded windows too. This already happened on macOS
for minimized windows via PauseCompositor, but this should be better and
more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D151818
Just like it manages content, so that we stop chrome animations and such
in hidden or fully-occluded windows too. This already happened on macOS
for minimized windows via PauseCompositor, but this should be better and
more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D151818
All its members are optional, so we can just use it as a plain struct
rather than Maybe<> all around, which simplifies the code and prevents
silly bugs like bug 1779592.
Mostly automatic via:
rg -l 'SVGImageContext' . | xargs sed -i 's/Maybe<SVGImageContext>/SVGImageContext/g'
With trivial build fixes.
Not intended to change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D151846
This is the only thing from the regressing patch that could potentially
cause this macOS leak, realistically. I don't think the leak is
super-worrisome, likely we just shut down the browser before the image
load finishes.
Differential Revision: https://phabricator.services.mozilla.com/D151368
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
This patch aligns the code paths for programmatic menu item activation and
user-initiated menu item activation.
Before this patch, user-initiated menu item activation caused
the command event to fire synchronously from menuItemHit.
After this patch, the command event fires from MenuClosedAsync,
which, if an item was activated, is called asynchronously once
the menu's nested event loop has been exited. (If no item has been
activated, MenuClosedAsync is called *inside* the menu's event
loop so that popuphiding / popuphidden events for submenus don't
get delayed.)
This patch makes three major changes to align the two code paths:
- menuItemHit now calls ActivateItemAfterClosing. This fixes bug 1748815.
- NativeMenuMac::ActivateItem (used in automated tests) calls the
relevant methods in the same order as user-initiated item activation.
This means that what we're testing is now closer to what we're shipping.
This patch also removes the call to runAfterMenuClosed. The runnable
that calls MenuClosedAsync is already guaranteed to run outside the
menu's event loop when a menu item was activated (I'm 99% sure about this):
For user-initiated activations, the macOS code exits the loop immediately
after calling menuItemHit and doesn't give our CFRunLoopSource another
chance to run until the stack is unwound. For test-initiated activations,
we set MOZMenuOpeningCoordinator.needToUnwindForMenuClosing which tells
our native event loop to not run anything until the stack is unwound.
Differential Revision: https://phabricator.services.mozilla.com/D149316
ActivateItemAfterClosing is currently only called during automated tests.
Before this patch, the DoCommandRunnable could be run from two different places:
Either from the regular event loop (dispatched in `-[MOZMenuOpeningCoordinator _runMenu]`
once the menu event loop is exited), or from MenuClosedAsync, whichever happens first.
MenuClosedAsync always runs when the menu closes, so we can rely on
it being called after ActivateItemAfterClosing.
So we can simplify the code by just always firing the command event
from MenuClosedAsync.
Differential Revision: https://phabricator.services.mozilla.com/D149315
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
Instead, have the menu popup frame call SetWindowMouseTransparent (since
it needs to anyways to deal with dynamic changes).
Differential Revision: https://phabricator.services.mozilla.com/D148211
This is regression by bug 666254. We shouldn't call
`nsClipborad::EmptyClipboard()` in destructor. Cached `nsITransferable` will
be cleared by nsBaseClipboard()'s destructor.
Differential Revision: https://phabricator.services.mozilla.com/D147834
This seems to effectively be the old SDK behavior, and fixes contrast
of dark popups on light backgrounds.
Version check might not be wanted / necessary, but I have no way to
test so I haven't touched old macOS versions without dark mode support.
Differential Revision: https://phabricator.services.mozilla.com/D147696
None of the consumer need to mutate styles, and this saves some ugly
const_casting on the next patch.
Doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D147555
After bug 1768278 and bug 1767815 there's no more uses of the cliprounded value
in the tree (also it causes artifacts on HiDPI screens so we probably don't
want new usages).
The "sheet" value is unused, and the other values other than "default" and
"none" are only derived from "default", so they don't need to be exposed in the
style system.
Differential Revision: https://phabricator.services.mozilla.com/D145821
Lately nsIPrintSession was only used to pass around RemotePrintJobChild objects.
Now that we pass those objects explicitly where needed (part 1), this class
serves no purpose.
Another reason to want to get rid of this class is that having it as a member
of nsIPrintSettings made no sense and was confusing.
Differential Revision: https://phabricator.services.mozilla.com/D146381
nsIPrintSettings is supposed to be a collection of settings passed to the
platform code to determine how the document prints. The
isPrintSelectionRBEnabled member doesn't belong here since it is a flag that
is passed to the OS native print settings dialog to tell it whether to
display a "Print selection only" radio button.
Depends on D146232
Differential Revision: https://phabricator.services.mozilla.com/D146251
nsIPrintSettings is supposed to be a collection of settings passed to the
platform code to determine how the document prints. The
isPrintSelectionRBEnabled member doesn't belong here since it is a flag that
is passed to the OS native print settings dialog to tell it whether to
display a "Print selection only" radio button.
Differential Revision: https://phabricator.services.mozilla.com/D146251
nsIPrintingPromptService comes from an era when the platform print code would
open the print settings dialog, which defaulted to the OS native dialogs.
Its purpose was to allow that dialog to be overridden by embedders to provide
their own interface for the user to select print settings. Nowadays the
platform print code does not open the dialogs. Instead apps like Firefox are
responsible for getting the print settings to pass to the platform code, and
the platform code provides a way to open the OS native print dialog if they
want to use that (nsIPrintDialogService). So nsIPrintingPromptService no longer
has any purpose, and just adds indirection and needless complexity.
Differential Revision: https://phabricator.services.mozilla.com/D146232
This removes a bunch of custom code from GfxInfo to obtain screen
information, and instead collects that screen information in
ScreenManager.
This, apart of removing duplicated code, has the extra benefit of
reporting multi-monitor information on GTK (and potentially in the
future reporting scale and refresh rate properly as well, I've kept the
telemetry as it was on that regard).
Differential Revision: https://phabricator.services.mozilla.com/D145178
This removes a bunch of custom code from GfxInfo to obtain screen
information, and instead collects that screen information in
ScreenManager.
This, apart of removing duplicated code, has the extra benefit of
reporting multi-monitor information on GTK (and potentially in the
future reporting scale and refresh rate properly as well, I've kept the
telemetry as it was on that regard).
Differential Revision: https://phabricator.services.mozilla.com/D145178
The existing code was relying on the drag event coordinates being
already unscaled by the zoom, which bug 1753836 fixed.
This simplifies the relevant code and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D145578
This member is no longer used on Windows, and having it in the
base class doesn't provide a real abstraction anyway since
the child classes will break if anything about it is changed.
Differential Revision: https://phabricator.services.mozilla.com/D145132
nsIPrintSettings.isCancelled was only being set to true by the Windows widget
code ShowNativePrintDialog nowadays. That seems pointless since that widget
code is only invoked under the _showPrintDialog call in print.js, and in the
case that the widget code throws, the print is never invoked and the
nsIPrintSettings object isn't used.
nsIPrintSettings.saveOnCancel was set in some places but never read.
Differential Revision: https://phabricator.services.mozilla.com/D144830
Bug 1757395 basically removed the reason for PPrinting to exist. What remained
essentially just added an unnecessary layer of complexity/indirection to the
creation of PRmotePrintJob actors.
Differential Revision: https://phabricator.services.mozilla.com/D143330
Actually, `nsIClipboard.emptyClipboard` on macOS doesn't clear system
clipboard. Since other platforms clear it, so I would like to change to same
behaviour.
Also, since we have base class of `nsIClipboard`, we should Inherit it to share
code.
Differential Revision: https://phabricator.services.mozilla.com/D143312
The trickiest bits are the PrintTargetCG ones, the rest is just plumbing
and cleanups and tests, but let me know if you want those to be split
out, can do.
The GTK change to nsPrintSettingsGTK::GetResolution is a no-op (we only
read resolution on windows), but I did that because we assume that it
doesn't fail and GTK returns a sane default anyways.
Differential Revision: https://phabricator.services.mozilla.com/D142199
The trickiest bits are the PrintTargetCG ones, the rest is just plumbing
and cleanups and tests, but let me know if you want those to be split
out, can do.
The GTK change to nsPrintSettingsGTK::GetResolution is a no-op (we only
read resolution on windows), but I did that because we assume that it
doesn't fail and GTK returns a sane default anyways.
Differential Revision: https://phabricator.services.mozilla.com/D142199
This matches Chrome behavior. Our video-dynamic-range media query also relies
on this value being greater than 24 in order to report "high" level support.
Differential Revision: https://phabricator.services.mozilla.com/D141306
This matches Chrome behavior. Our video-dynamic-range media query also relies
on this value being greater than 24 in order to report "high" level support.
Differential Revision: https://phabricator.services.mozilla.com/D141306
This matches Chrome behavior. Our video-dynamic-range media query also relies
on this value being greater than 24 in order to report "high" level support.
Differential Revision: https://phabricator.services.mozilla.com/D141306
Emilio Cobos Álvarez
Iulian Moraru
Butkovits Atila
Florian Quèze
Gijs Kruitbosch
Tom Schuster
Sandor Molnar
Edgar Chen
Matthew Noorenberghe
Nicholas Rishel
Olli Pettay
Sylvestre Ledru
Ben Freist
David Shin
Brad Werth
Jonathan Watt
Ryan VanderMeulen
Marian-Vasile Laza
Botond Ballo
Hiroyuki Ikezoe
Morgan Rae Reschenberg
Stephen A Pohl
Csoregi Natalia
Adam Vandolder
Andrew Osmond
Cristian Tuns
Jan-Niklas Jaeschke
kriswright
Andrew McCreight
Greg Tatum
Norisz Fay
Kagami Sascha Rosylight
Fabrice Desré
Andreea Pavel
Haik Aftandilian
Markus Stange
Bogdan Szekely
Kris Maglione
Noemi Erli
criss
Sean Burke
Makoto Kato
Karl Tomlinson
Dmitrij Feller
Cosmin Sabou
Chris Martin
Randell Jesup