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
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
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
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
This ensures that you can't observe an inconsistent state while we go
through the list.
It should also be marginally better as we don't build an array with all
the media queries unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D82260
This is a straightforward conversion except that
`NS_SUBTREE_DIRTY(this)` can be written terser as `IsSubtreeDirty()`.
Differential Revision: https://phabricator.services.mozilla.com/D82811
Note: This optimization saves us from doing an extra unnecessary reflow in the
mochitest test_bug1505254.html, so I'm adjusting that test to remove its
magical "+1" fudge-factor in its expectations (and the corresponding
explanatory comment). Similarly, I'm dropping the assertion-count for
crashtest 1488762-1.html because we now do a little bit less reflow work (and
hence assert a little bit less) in that test.
Depends on D78821
Differential Revision: https://phabricator.services.mozilla.com/D78822
It leaves parent pointers nulled out when it really shouldn't when
cloning shared sheets (if there's another suitable parent, we should use
that instead of nulling out).
Fix the code in StyleSheetInfo::RemoveSheet to handle all cases
(including nulling out when removing the only remaining sheet), and rely
on that instead.
Differential Revision: https://phabricator.services.mozilla.com/D81569
Consider the case where we have an expired entry in the cache, and we
load a new document.
We get an speculative load from the HTML parser. That's great, and we
see the entry is expired and actually fired the load.
But then, we actually get to the load that the <link> element performs,
and we see that we've already performed this load, so instead of peeking
the in-progress load, we go ahead and peek the expired "complete" cache
entry, which is not what we want.
By marking a load as performed only once it has finished, we avoid the
complete sheet cache, and glom onto the existing load instead, which is
the correct thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D81318
Consider the case where we have an expired entry in the cache, and we
load a new document.
We get an speculative load from the HTML parser. That's great, and we
see the entry is expired and actually fired the load.
But then, we actually get to the load that the <link> element performs,
and we see that we've already performed this load, so instead of peeking
the in-progress load, we go ahead and peek the expired "complete" cache
entry, which is not what we want.
By marking a load as performed only once it has finished, we avoid the
complete sheet cache, and glom onto the existing load instead, which is
the correct thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D81318
When we call into LoadSheet when starting pending loads for a given
loader, it may be the case that the original loader may still not care
about the load. However some other loader will, so we can't defer this.
This was also causing our state to get out of sync, because if this
happened, then we'd fail to account for it in other loaders.
Differential Revision: https://phabricator.services.mozilla.com/D81119
Handle grid track lists that are too large in CalculateRepeatFillCount. Check
for repeat tracks that begin or end past the maximum track limit in
InitRepeatTracks, and handle the possible size mismatch in nsComputedDOMStyle.
This may result in there being fewer than the maximum number of tracks again
after removing empty tracks in a repeat(auto-fit), but only limiting the track
count after removing empty tracks would leave the number of repeat tracks
unbounded (or require a separate limit on just the repeat track count).
Differential Revision: https://phabricator.services.mozilla.com/D76191
If two loading documents hit the sheet cache and we coalesce the
resource load, there's nothing that prevents the load event on the
second document from firing right now, and there should be.
While at it, also fix the handling of the pending load count, though
it has no correctness impact on the particular test we're fixing here...
We were never decrementing it, which is of course wrong. However it
kinda ended up working because it just causes us to not defer more
loads.
The new assertions and responsibility of the counter should ensure it
stays correct.
Differential Revision: https://phabricator.services.mozilla.com/D80583
So as to make sense in a world where we can coalesce loads across
documents. The per-load object is the SheetLoadData, so this way we
guarantee that we fire the right events in presence of the load
coalescing that the SharedStyleSheetCache does.
Differential Revision: https://phabricator.services.mozilla.com/D80380
This shouldn't have any behavior change, but it makes the code make a
bit more sense. Rather than counting inline stylesheets like a pending
load, we won't (but note that any @import inside it will).
The SheetLoadData::mURL it's supposed to be the url of the stylesheet,
so for StyleSheet::Replace it should be null.
Differential Revision: https://phabricator.services.mozilla.com/D80379
This makes it easy to see why your test is not failing without your
patch, for example ;)
Note that we log only when the URIs are the same, which
I think is a reasonable compromise in verbosity.
Differential Revision: https://phabricator.services.mozilla.com/D80288
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
We've had nsNativeBasicTheme enabled since 75, and all reported issues
were fixed real soon (and I haven't heard of any of them recently).
Given the non-native theme is likely changing in the future, I'd rather
not maintain three themes for Android :)
Differential Revision: https://phabricator.services.mozilla.com/D80105
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
We're converting to nscoord in some places unnecessarily, reducing the
precision of the computed value we return.
This makes some tests unnecessarily fail if we change the base of
nscoord.
Differential Revision: https://phabricator.services.mozilla.com/D79996
Handle grid track lists that are too large in CalculateRepeatFillCount. Check
for repeat tracks that begin or end past the maximum track limit in
InitRepeatTracks, and handle the possible size mismatch in nsComputedDOMStyle.
This may result in there being fewer than the maximum number of tracks again
after removing empty tracks in a repeat(auto-fit), but only limiting the track
count after removing empty tracks would leave the number of repeat tracks
unbounded (or require a separate limit on just the repeat track count).
Differential Revision: https://phabricator.services.mozilla.com/D76191
We're converting to nscoord in some places unnecessarily, reducing the
precision of the computed value we return.
This makes some tests unnecessarily fail if we change the base of
nscoord.
Differential Revision: https://phabricator.services.mozilla.com/D79996
This basically undoes D77842, but it was better done on top than just
removing the patch from the stack. I could squash them if desired.
The previous patch to respect caching headers makes tests much much more
happy, to the point where I'm not sure whether we really need this or
not. Your call whether we should keep it or not.
Differential Revision: https://phabricator.services.mozilla.com/D78660
Make the stylesheet cache respect the same headers as the image cache
does. This makes no-cache stylesheets work as they do now, which is
useful for developers that want to develop sites locally, and for
shift-reloads, etc.
Differential Revision: https://phabricator.services.mozilla.com/D78659
This patch implements a per-process cache of parsed stylesheets for
non-inline sheets. The entries are evicted when the document gets
destroyed and there's no other document with the same principal around.
This works fine in practice even when navigating because CC happens
pretty late, but we could add an extra timer if we deem it worth it.
I had to adapt some tests so that they keep passing. They were already
clearing various image / network caches so it seems fine to also clear
this one.
Note that there's a very subtle change in the load data key: We only
miss the cache if the referrer _policy_ is different, not if the
referrer is different. While that is slightly dubious, that is the only
think that makes this effort somewhat worth it. Otherwise stylesheets
would have to be re-fetched if the referrer is different, which
effectively would mean to re-parse it if the document URI is different,
which is bad.
It seems like the network cache only keys on the referrer policy, so it
seems fine to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D77457
This basically undoes D77842, but it was better done on top than just
removing the patch from the stack. I could squash them if desired.
The previous patch to respect caching headers makes tests much much more
happy, to the point where I'm not sure whether we really need this or
not. Your call whether we should keep it or not.
Differential Revision: https://phabricator.services.mozilla.com/D78660
Make the stylesheet cache respect the same headers as the image cache
does. This makes no-cache stylesheets work as they do now, which is
useful for developers that want to develop sites locally, and for
shift-reloads, etc.
Differential Revision: https://phabricator.services.mozilla.com/D78659
This patch implements a per-process cache of parsed stylesheets for
non-inline sheets. The entries are evicted when the document gets
destroyed and there's no other document with the same principal around.
This works fine in practice even when navigating because CC happens
pretty late, but we could add an extra timer if we deem it worth it.
I had to adapt some tests so that they keep passing. They were already
clearing various image / network caches so it seems fine to also clear
this one.
Note that there's a very subtle change in the load data key: We only
miss the cache if the referrer _policy_ is different, not if the
referrer is different. While that is slightly dubious, that is the only
think that makes this effort somewhat worth it. Otherwise stylesheets
would have to be re-fetched if the referrer is different, which
effectively would mean to re-parse it if the document URI is different,
which is bad.
It seems like the network cache only keys on the referrer policy, so it
seems fine to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D77457
Spec: https://html.spec.whatwg.org/multipage/#centered-alignment
The spec is opaque about the centered alignment mode and we couldn't
come up a satisfied solution by using the current version of the
spec. There will be discussion in CSSWG to talk about better solutions.
In the meantime, we are adding this patch as a temporary solution with
basic centered alignment support to allow us enabling the feature
in Nightly for more testing.
Differential Revision: https://phabricator.services.mozilla.com/D77678
This seems to match what other browsers do, and seems saner layout-wise,
at least.
I only annotated outline-width-interpolation.html because it's already
fixed upstream in:
8a489657bc
Differential Revision: https://phabricator.services.mozilla.com/D75360
This patch was largely automated. It was generated by manually
editing .eslintrc.js and then running mach eslint layout --fix.
Additionally, this includes manual changes to test_bug533845.xhtml
and test_bug467442.xhtml that were necessary to appease eslint.
Differential Revision: https://phabricator.services.mozilla.com/D78615
The background color for the tree column headers is drawn using the
system APIs, but the foreground uses custom colors, which didn't follow
theme. This can lead to unreadable text with specific colors, e.g.
leading to black on black.
Fix this by using system colors for the foreground as well. It also
adds on-hover styling to match possible background change on hover.
Differential Revision: https://phabricator.services.mozilla.com/D78073
Rather than waiting until parsing another id (successfully or
unsuccessfully).
If we error before we even get to PropertyId::parse, we'd incorrectly
associate the error with the wrong property, incorrectly omitting it
sometimes.
Differential Revision: https://phabricator.services.mozilla.com/D78260
Spec: https://html.spec.whatwg.org/multipage/#centered-alignment
The spec is opaque about the centered alignment mode and we couldn't
come up a satisfied solution by using the current version of the
spec. There will be discussion in CSSWG to talk about better solutions.
In the meantime, we are adding this patch as a temporary solution with
basic centered alignment support to allow us enabling the feature
in Nightly for more testing.
Differential Revision: https://phabricator.services.mozilla.com/D77678
Spec: https://html.spec.whatwg.org/multipage/#centered-alignment
The spec is opaque about the centered alignment mode and we couldn't
come up a satisfied solution by using the current version of the
spec. There will be discussion in CSSWG to talk about better solutions.
In the meantime, we are adding this patch as a temporary solution with
basic centered alignment support to allow us enabling the feature
in Nightly for more testing.
Differential Revision: https://phabricator.services.mozilla.com/D77678
Also update documentation to suggest using the `GeneratedFile` template rather than directly referencing `GENERATED_FILES` where possible.
Differential Revision: https://phabricator.services.mozilla.com/D77496
I'm about to introduce the concept of "Loader principal" (as in "the
principal of the CSS loader"), and SheetLoadData already has an
mLoaderPrincipal.
However SheetLoadData's principal is just the triggering principal (the
principal that initiated the load). So name it that with consistency
with SheetInfo::mTriggeringPrincipal etc.
Differential Revision: https://phabricator.services.mozilla.com/D77613
Simon Giesecke
Frederik Braun
Emilio Cobos Álvarez
Daniel Holbert
longsonr
Liang-Heng Chen
sefeng
Ting-Yu Lin
Daisuke Akatsuka
Bogdan Tara
Csoregi Natalia
Kagami Sascha Rosylight
Sylvestre Ledru
Zeke Medley
Razvan Maries
Coroiu Cristina
Emily McDonough
Honza Bambas
tkhan
Jonathan Kew
Cosmin Sabou
Brindusan Cristian
Gijs Kruitbosch
Noemi Erli
Philipp Zech
neil
Butkovits Atila
Kenrick
Colomban Wendling
Cameron McCormack
Dorel Luca
Narcis Beleuzu
Ricky Stewart