Instead add a pseudo-class that does the expected size="" attribute parsing.
Removing the Gtk-specific rule setting the text color since it doesn't
seem to have any effect currently.
Differential Revision: https://phabricator.services.mozilla.com/D83448
The patches in the stack were backed out because of an unexpected pass in the resulting push.
The expectations for now-passing tests have been updated.
Differential Revision: https://phabricator.services.mozilla.com/D83987
Forgot to follow up on these two remaining non-standard values that may have
been being used to reset a <meter> or <input type=number> back to its
original appearance, but which telemetry showed no usage of.
Differential Revision: https://phabricator.services.mozilla.com/D83598
This includes all of the <compat-auto> values, plus menulist-button,
which doesn't behave any differently from menulist currently.
Differential Revision: https://phabricator.services.mozilla.com/D83436
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
This is safer in case Necko fails to notify us. The only repro we have
is fixed by bug 1651661, but this should hopefully be uncontroversial as
well and prevents crashing in release builds.
Differential Revision: https://phabricator.services.mozilla.com/D83642
When doing a display list build, there's some code that expands the dirty
and visible rects for out-of-flow items to include the entire visual viewport
or displayport, because out-of-flow items are specially positioned in the
compositor and may become visible without the main thread knowing about it.
However, this happens even during partial updates using retained display lists,
which I believe is undesirable because the preceding non-partial update should
already have painted all the right things. The partial update should be
restricted to the part of the OOF item that actually need repainting, and the
merging of the partial update into the full display list should produce a final
display list that covers everything.
Differential Revision: https://phabricator.services.mozilla.com/D82216
Fixes a missing closing tag in the retained-dl-style-change-stacking-context-3
test page. Unfortunately, this changes the structure of the page and makes the
test fail, so the reftest.list file is updated accordingly. Since the existing
test structure was clearly testing something else, and caught a legitimate
difference in behaviour with and without APZ zooming on desktop, this patch
also creates a new test with that structure (and better indentation).
Differential Revision: https://phabricator.services.mozilla.com/D82214
We always use PreventDefault for <select> element, which is
problematic if modal dialog is on as it prevents cancelling
the dialog.
We fix it by not blocking the default action if <select> is
not shown.
Differential Revision: https://phabricator.services.mozilla.com/D82590
This is going to be useful for the new print preview UI, which is in a
doorhanger and thus much more likely to be less than the page size.
We (ab)use the existing print preview scaling mechanism. We only need it
after reflowing all pages, so this works.
This whole scaling mechanism is all-in-all not amazing, but the patch is
less gross than I initially thought. It's nice, actually.
We could put the new behavior behind a pref trivially, if that's wanted,
but I honestly thing this behavior is better even without the doorhanger
ui.
Differential Revision: https://phabricator.services.mozilla.com/D83309
Also removes some mozilla:: where its no longer needed
Note that this patch was created by running
sed -e -i '.bak' 's/typedef ([a-zA-Z0-9:]+) ([a-zA-Z0-9:]+)/using \2 = \1/'
and then fixing up a few cases that didn't work.
Differential Revision: https://phabricator.services.mozilla.com/D83294
This hooks the "monochrome" media query and co to the
nsIPrintSettings.printInColor setting.
This print setting we're using is not exposed in the print preview UI,
but you can test it setting the print.print_in_color preference to
"false", and then print preview will correctly show up greyscale'd.
Once this lands, the UI folks just have to use it as they see fit :)
I would've liked to add a proper rendering test, but the print reftests
check only whether the PDF text matches.
I could add a test to printpreview_helper.xhtml, but I'm refactoring
that file in bug 1648064 so I'd rather wait a bit and add it in a
separate bug. The test for the media feature should make sure that we
test that code path at least.
Differential Revision: https://phabricator.services.mozilla.com/D83552
The only possible behavior change is in
nsIFrame::MarkIntrinsicISizesDirty(). Before this patch, we clear
CachedFlexItemData for every child frame under nsFlexContainerFrame.
However, only flex items can have cache, so we can use IsFlexItem() to
replace the usage.
Differential Revision: https://phabricator.services.mozilla.com/D83454
If there are mix-blend-mode items inside the async zoom container, the
BlendContainer can end up outside the async zoom container, at the top-level
stacking context. But this causes the blend mode to fail with WebRender.
Instead, if we are creating an async zoom container, we check to see if there
was a mix-blend-mode inside it, and create the blend container just inside
the async zoom container.
Differential Revision: https://phabricator.services.mozilla.com/D82186
Per documentation, `aPositionedFrame` (the second argument) of
`PushAbsoluteContainingBlock` should be the frame whose style actually
makes the new absolute containing block a containing block, so it should
be the fieldset frame itself, not fieldset's inner frame.
Co-authored-by: Mats Palmgren <mats@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D82651
Before this patch, the test tries to remove all children from the 'content'
node except for one, as part of cleaning up. This is unnecessary, because none
of the subtests ever add any additional children to the 'content' element.
(It's also problematic because in late beta & release, 'content' is a special
variable name by default.)
While we're at it, this patch also makes us address the other nodes more
consistently, using the explicit variable declarations at the top of the
script section rather than their implicit ID-granted variable names.
Differential Revision: https://phabricator.services.mozilla.com/D83251
- Add macOS-specific function to retrieve the paper list for a given printer.
- Add JS test to ensure papers are initialized with valid values.
Differential Revision: https://phabricator.services.mozilla.com/D82598
- Add macOS-specific function to retrieve the paper list for a given printer.
- Add JS test to ensure papers are initialized with valid values.
Differential Revision: https://phabricator.services.mozilla.com/D82598
These classes are both 'final', so it's pointless for them to declare their own
(non-overriding) virtual functions. They can't have any subclasses, so it would
be impossible for there to be polymorphism in these virtual funtions'
implementation. So, let's de-virtualize them.
(I'm guessing these date from the early Mozilla days when methods needed to be
virtual in order to be called from other components, or something like that.)
Differential Revision: https://phabricator.services.mozilla.com/D83234
DONTBUILD because this is a comment-only change.
Before this patch, these comments all mentioned "simple page sequence frame",
which is no longer a thing (it's been renamed to nsPageSequenceFrame). This
patch fixes that and corrects/clarifies these comments while we're at it.
(Note that these comments/classes may change a bit, as part of future patches
for the "pages-per-sheet" feature. This patch here is partly to get them to a
coherent starting state, for that work to build from.)
Differential Revision: https://phabricator.services.mozilla.com/D83233
The fallback code in nsPrintJob::DoCommonPrint to create an nsIPrintSettings if
none is passed in is never used, since all callers pass a settings object.
However, to simplify future changes I'd like nsGlobalWindowOuter::PrintOuter to
stop creating and passing in its own default valued nsIPrintSettings object.
This patch makes the fallback code that DoCommonPrint calls do what
nsGlobalWindowOuter::PrintOuter does, and makes the latter stop passing in a
settings object.
This patch also removes nsIWebBrowserPrint.globalPrintSettings since
nsGlobalWindowOuter::PrintOuter was its only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D83268
nsIWebBrowserPrint.globalPrintSettings returns a new object each time. That is
why the code in these tests doesn't work, and why they have the workaround to
set the pref to disable the progress dialog. This patch fixes the code and
removes the prefs setting workaround.
This patch also changes the code to use the print settings service to get the
print settings. That's all that nsIWebBrowserPrint.globalPrintSettings does
anyway. Making this change allows me to remove
nsIWebBrowserPrint.globalPrintSettings in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D83279
The fallback code in nsPrintJob::DoCommonPrint to create an nsIPrintSettings if
none is passed in is never used, since all callers pass a settings object.
However, to simplify future changes I'd like nsGlobalWindowOuter::PrintOuter to
stop creating and passing in its own default valued nsIPrintSettings object.
This patch makes the fallback code that DoCommonPrint calls do what
nsGlobalWindowOuter::PrintOuter does, and makes the latter stop passing in a
settings object.
This patch also removes nsIWebBrowserPrint.globalPrintSettings since
nsGlobalWindowOuter::PrintOuter was its only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D83268
I'm going to be splitting DoCommonPrint so that the parts that run after the
static clone is created happen after a roundtrip to the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D83262
I specifically want to move this to happen before the static clone is made, in
preparation for splitting out the static clone logic from DoCommonPrint.
Differential Revision: https://phabricator.services.mozilla.com/D83260
I'm going to be splitting DoCommonPrint so that the parts that run after the
static clone is created happen after a roundtrip to the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D83262
I specifically want to move this to happen before the static clone is made, in
preparation for splitting out the static clone logic from DoCommonPrint.
Differential Revision: https://phabricator.services.mozilla.com/D83260
- Add macOS-specific function to retrieve the paper list for a given printer.
- Add JS test to ensure papers are initialized with valid values.
Differential Revision: https://phabricator.services.mozilla.com/D82598
This fixes two issue.
First, the code shouldn't be dispatching these events every time it gets a new
Print or PrintPreview call. It only needs to dispatch the events to the
original document that we're going to clone from. When cloning from existing
static clones any changes made by 'beforeprint' will be present in the existing
static clone.
Second, the code tries to delay the 'afterprint' event until after
mozPrintCallback callbacks have been invoked, but those callbacks are invoked
in the cloned document, whereas the events are sent to the original document!
So there is no reason to do this.
Differential Revision: https://phabricator.services.mozilla.com/D34280
This fixes two issue.
First, the code shouldn't be dispatching these events every time it gets a new
Print or PrintPreview call. It only needs to dispatch the events to the
original document that we're going to clone from. When cloning from existing
static clones any changes made by 'beforeprint' will be present in the existing
static clone.
Second, the code tries to delay the 'afterprint' event until after
mozPrintCallback callbacks have been invoked, but those callbacks are invoked
in the cloned document, whereas the events are sent to the original document!
So there is no reason to do this.
Differential Revision: https://phabricator.services.mozilla.com/D34280
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
Ting-Yu Lin
longsonr
Bob Clary
Narcis Beleuzu
Alexander Surkov
Butkovits Atila
Cameron McCormack
Edwin Takahashi
Emilio Cobos Álvarez
manas
Kartikaya Gupta
Mihai Alexandru Michis
sefeng
Simon Giesecke
Frederik Braun
Daniel Holbert
Sylvestre Ledru
Erik Nordin
tkhan
Kagami Sascha Rosylight
Bogdan Tara
Jonathan Watt
Hiroyuki Ikezoe
Csoregi Natalia
Jonathan Kew
Razvan Maries
Kris Maglione
Liang-Heng Chen