0c42cb5532d79c78803208c0c25f0aa00ec27ad5: Bug 1180715 (4/4) - Use nsIURL methods instead of RegExp. review=ttaubert
Oliver Henshaw <oliver.henshaw@gmail.com> - Tue, 20 Oct 2015 10:45:40 +0530 - rev 303649
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1180715 (4/4) - Use nsIURL methods instead of RegExp. review=ttaubert Also move host check from the parseURI caller to parseURI itself.
7b4f0495cf6d5f40298755b6d8d15434f449fa0c: Bug 1180715 (2/4) - Provide a nsIFileURL interface for thumbnails. review=ttaubert
Oliver Henshaw <oliver.henshaw@gmail.com> - Tue, 20 Oct 2015 10:45:32 +0530 - rev 303648
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1180715 (2/4) - Provide a nsIFileURL interface for thumbnails. review=ttaubert 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.
38558bb6671b53b51716c9a8d897b9eb1f3668a8: Bug 1180715 (1/4) - Track image LoadTime to compare with file mtime. review=seth
Oliver Henshaw <oliver.henshaw@gmail.com> - Tue, 20 Oct 2015 10:45:25 +0530 - rev 303647
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1180715 (1/4) - Track image LoadTime to compare with file mtime. review=seth 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.)
4e79bfe043c8419874fff97657178408eb51ea63: Bug 1215517 part.3 Test the result of eQuerySelectedText in runSetSelectionEventTest() for checking the behavior of ContentEventHandler::GetFlatTextOffsetOfRange() rs=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 20 Oct 2015 14:14:17 +0900 - rev 303646
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1215517 part.3 Test the result of eQuerySelectedText in runSetSelectionEventTest() for checking the behavior of ContentEventHandler::GetFlatTextOffsetOfRange() rs=smaug
9f97448cf56a8f5fe758f9d0ab271d87fb4f3aa7: Bug 1215517 part.2 Add tests for eQueryTextContent event in rich text editor r=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 20 Oct 2015 14:14:17 +0900 - rev 303645
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1215517 part.2 Add tests for eQueryTextContent event in rich text editor r=smaug
80d578836131322040a650a1a7672a4f84fa9a98: Bug 1215517 part.1 Add tests for eSetSelection event in rich text editor rs=smaug
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 20 Oct 2015 14:14:17 +0900 - rev 303644
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1215517 part.1 Add tests for eSetSelection event in rich text editor rs=smaug
7dedd0f85f8b1be2230287e73b4906c5b1165996: Bug 1216287 - Properly invalidate the debug overlay. r=mattwoodrow
Benoit Girard <b56girard@gmail.com> - Mon, 19 Oct 2015 18:03:48 -0400 - rev 303643
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1216287 - Properly invalidate the debug overlay. r=mattwoodrow
d630beb006c9969707aa3216365f9fc064fa6205: Back out 069effcd9de6 (bug 1108181) for wpt bustage that shouldn't have happened
Phil Ringnalda <philringnalda@gmail.com> - Mon, 19 Oct 2015 21:21:56 -0700 - rev 303642
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Back out 069effcd9de6 (bug 1108181) for wpt bustage that shouldn't have happened
48fff3ec4d8113bff05b4dd484f2e5a5481f2f9d: Bug 1215424 - Convert ParseBoxProperty to CSSParseResult and remove ParseBoxPropertyVariant. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:29 -0700 - rev 303641
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1215424 - Convert ParseBoxProperty to CSSParseResult and remove ParseBoxPropertyVariant. r=heycam
bb679653777502d9099a403520ed8b17da936e3f: Bug 1209603 patch 11 - Assert that PeekStyle* results don't change during difference computation. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:29 -0700 - rev 303640
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1209603 patch 11 - Assert that PeekStyle* results don't change during difference computation. r=heycam 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.
b2c58421d657b4de854528dcd1c81fda17acddc5: Bug 1209603 patch 10 - Make PeekStyle* exact, i.e., guaranteed to return null if we haven't computed the data for this context. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:29 -0700 - rev 303639
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1209603 patch 10 - Make PeekStyle* exact, i.e., guaranteed to return null if we haven't computed the data for this context. r=heycam 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.
0f3e25c8e4b1a37d809d4e777edfa4d10df5cf60: Bug 1209603 patch 9 - Cache inherited style structs on the style context when we found already-cached data in the rule tree. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:29 -0700 - rev 303638
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1209603 patch 9 - Cache inherited style structs on the style context when we found already-cached data in the rule tree. r=heycam 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.
573bb4c9a1da8d44ebb8dfed37bdf47f449139b8: Bug 1209603 patch 8 - Record in mBits when we have gotten a reset style struct that is cached on the rule node. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:29 -0700 - rev 303637
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1209603 patch 8 - Record in mBits when we have gotten a reset style struct that is cached on the rule node. r=heycam 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.
514b6bfc3f3896ee44a5c75698c10ff94a6855b1: Bug 1209603 patch 7 - Add assertions that we don't ask the rule node for data when we have cached data on the style context. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:28 -0700 - rev 303636
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1209603 patch 7 - Add assertions that we don't ask the rule node for data when we have cached data on the style context. r=heycam These document an invariant that I depend on in the next patch.
fcd8749d260ccb60fe7f8e07303ce40391652a29: Bug 1209603 patch 6b - Rename nsStyleContext::HasCachedInheritedStyleData to HasCachedDependentStyleData. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:28 -0700 - rev 303635
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1209603 patch 6b - Rename nsStyleContext::HasCachedInheritedStyleData to HasCachedDependentStyleData. r=heycam
565c13fd9230597dd9cda4cb1c2fe66bc4f89f34: Bug 1209603 patch 6 - Prepare to use a different meaning of mBits when cached style data pointer is null. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:28 -0700 - rev 303634
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1209603 patch 6 - Prepare to use a different meaning of mBits when cached style data pointer is null. r=heycam 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.
415be6e995fdac614a00a85554076e2f3073d1ec: Bug 1209603 patch 5 - Move inline method nsStyleContext::GetCachedStyleData into header file, and make it public. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:28 -0700 - rev 303633
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1209603 patch 5 - Move inline method nsStyleContext::GetCachedStyleData into header file, and make it public. r=heycam 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.
5eb95277f18cc839e3d18394a6d77cec626682e2: Bug 1209603 patch 4 - Add reftest for bug 1209603. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:28 -0700 - rev 303632
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1209603 patch 4 - Add reftest for bug 1209603. r=heycam
a8afd14e9d0b04c8be62695e5c6a22130544c7e8: Bug 1209603 patch 3 - Don't call SetFontSizeDependency for 0em. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:28 -0700 - rev 303631
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1209603 patch 3 - Don't call SetFontSizeDependency for 0em. r=heycam This should be a bit of an optimization for cases where '0em' is the only 'em' unit in a style struct.
b558ca528f4d0df37426d2b1080e94b19db1385e: Bug 1209603 patch 2 - Reduce calls to StyleVisibility() in WritingMode constructor. r=heycam
L. David Baron <dbaron@dbaron.org> - Mon, 19 Oct 2015 20:42:28 -0700 - rev 303630
Push 1001 by raliiev@mozilla.com at Mon, 18 Jan 2016 19:06:03 +0000
Bug 1209603 patch 2 - Reduce calls to StyleVisibility() in WritingMode constructor. r=heycam (I noticed this while writing patch 1.)
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip