This is a mechanism that should not exist; any use of it means
nonconformance with http://www.w3.org/TR/CSS/#partial .
--HG--
extra : commitid : fI2rko2cf4
We're violating http://www.w3.org/TR/CSS/#partial by leaving this
implementation in when we don't actually support the properties.
We're also incorrectly parsing marks and size in style rules rather than
@page rules; they were only intended for @page rules.
--HG--
extra : commitid : EV7bQDBQUp8
Use nsISubstitutingProtocolHandler to return a SubstitutingURL and to
resolve the thumbnail URL to the backing nsIFile.
Now the image loader code will realise that moz-page-thumb:// URLs are
backed by a file and will be able to use the file mtime to evaluate
whether the cached imgRequest has expired.
* Implement the nsISubstitutingProtocolHandler methods in the thumbnail
protocol handler. The resolveURI method does all the work, the other
methods are just stubs.
* moz-page-thumb:// is now an URL rather than an URI, so update the
signature accordingly.
* Add xpcshell-test to affirm that SubstitutingURL::EnsureFile()
resolves the backing file correctly.
* Adjust the mochitest to account for the one second granularity of the
mtime tracking.
mTouchedTime is not appropriate for this as it is updated when an image
load re-uses the same imgRequest, especially as it has one second
granularity. A timestamp that is updated every time the backing file is
re-read should work better.
A millisecond granularity timestamp would be preferable, and would be
achievable on most or all supported platforms. But some older
filesystems have timestamp granularity of a second or worse, notably
ext3 and FAT32 (and even ext4 filesytems created with inode_size < 256
bytes, e.g. with 'mke2fs -t small' - see
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inode_Timestamps
for details.)
This assertion catches the condition that led to the bug.
I confirmed that without patch 10 on this bug, the assert fires on the
reftest added in patch 4, but does not fire on slight modifications of
that testcase that don't show the bug.
--HG--
extra : commitid : 6VMNCelDQg9
This fixes the bug because it prevents a cache conditions check for a
later PeekStyle* in nsStyleContext::CalcStyleDifference from computing a
struct that was null when we checked it earlier in CalcStyleDifference.
This, in turn, could allow the old context to be retained (and
reparented to the new parent) even though it now has incorrect data in
the font or visibility struct that was computed while checking the
conditions for another struct.
This should also improve performance in some cases of style changes on
not-yet-presented frames because we have fewer change hints to process.
--HG--
extra : commitid : 16o8oS0RLfx
This means we obey the invariant that if we've requested an inherited
struct on a context, that struct will be cached on the style context. I
believe bug 527977 intended to do make us obey this invariant, but it
missed the case where nsRuleNode::GetStyle* found cached data already on
the rule node, and the case where nsRuleNode::WalkRuleTree found a
usable struct higher in the rule tree.
Without this change, patch 10 will not function correctly for inherited
structs when we encounter this case, and will cause assertions in
dom/base/test/test_bug560780.html due to triggering style change hints
on text nodes that inherited a color struct from a parent on whose rule
node the struct was stored. (It may also have caused some of the other
test failures.)
This should be a clear performance improvement, since the path that's
being slowed down by the added work in this patch will, with the patch,
now only execute once because of that work.
--HG--
extra : commitid : 5hueOZihqNx
I'm a little worried about the performance of the change to
nsRuleNode::GetStyle*, which sets a bit on the style context every time
a struct getter goes through it. It's not obvious how that compares to
the performance benefit from patch 10.
--HG--
extra : commitid : J2XERgJ7mh2
We currently only use the style struct bits in mBits when the style
context has the relevant struct cached. The bit being set indicates
whether or not the context owns the struct.
This patch conditions the necessary tests on a cached struct being
present so that we can use (for reset structs, i.e., those with
non-inherited properties) mBits to mean something different when the
cached storage is null.
--HG--
extra : commitid : 5UtmPx56nae
Moving it to the header allows its use by another method in the header
file, in patch 6.
Making it public allows its use in assertions in nsRuleNode in patch 7.
--HG--
extra : commitid : EL4WTKW32KS
DONTBUILD because it only changes comments.
This will hopefully prevent confusion like that in bug 1215903.
--HG--
extra : rebase_source : f0a601d77b5f42b4fbe090693234f934e3becc42
Botond Ballo
Sotaro Ikeda
Jeremy Chen
Cykesiopka
Nigel Babu
Makoto Kato
L. David Baron
Andrea Marchesini
Oliver Henshaw
Masayuki Nakano
Benoit Girard
Phil Ringnalda
Nicholas Nethercote
Dan Glastonbury
Chris Peterson
Jonas Sicking
Ehsan Akhgari
Christoph Kerschbaumer