Closed
Bug 1061364
Opened 10 years ago
Closed 10 years ago
Remove additional setting of mNeedsRefreshes = true to nsTransitionManager::WalkTransitionRule
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
mozilla40
Tracking | Status | |
---|---|---|
firefox40 | --- | fixed |
People
(Reporter: birtles, Assigned: birtles)
References
Details
Attachments
(1 file)
(deleted),
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
In Bug 1025709, an additional setting of mNeedsRefreshes = true as added to nsTransitionManager::WalkTransitionRule:
http://hg.mozilla.org/mozilla-central/rev/31695984cfe2#l5.65
now at:
http://hg.mozilla.org/mozilla-central/file/738469449872/layout/style/nsTransitionManager.cpp#l655
According to bug 1048838 comment 19 this may cause unnecessary work when we have multiple style flushes.
We should see if there is a way to remove this. Also, while we're at it, as also mentioned in bug 1048838 comment 19, we should also investigate why WalkTransitionRule needs a null-check.
Comment 1•10 years ago
|
||
For what it's worth:
* I've been running for at least a month (desktop and B2G phone) with the mNeedsRefreshes = true removed, and haven't noticed any problems.
* there was a problem when I removed the null-check
Comment 2•10 years ago
|
||
I removed the removal from my tree because it was breaking all but the first transition in https://bug1110277.bugzilla.mozilla.org/attachment.cgi?id=8535092 , at least back when I was debugging that testcase.
Assignee | ||
Comment 3•10 years ago
|
||
This works for me, even for the test case in comment 2. Applies on top of the patch for bug 1117603.
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → bbirtles
Status: NEW → ASSIGNED
Comment 4•10 years ago
|
||
Comment on attachment 8576461 [details] [diff] [review]
Don't force transitions to refresh their style rule
r=dbaron
Attachment #8576461 -
Flags: review+
Assignee | ||
Comment 5•10 years ago
|
||
I'm waiting for bug 1117603 to land before I land this.
Assignee | ||
Comment 6•10 years ago
|
||
Looks like this might trigger a test failure after all:
browser/components/customizableui/test/browser_989751_subviewbutton_class.js | Uncaught exception - Condition timed out: () => !PanelUI.multiView.hasAttribute("transitioning")
Assignee | ||
Comment 7•10 years ago
|
||
Assignee | ||
Comment 8•10 years ago
|
||
After some changes in bug 1117603, looks like this might be ok now but I've retriggered the jobs that failed last time in case I just happened to get lucky:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7c0d57b67523
Assignee | ||
Comment 9•10 years ago
|
||
Comment 10•10 years ago
|
||
Backed out because it blocked bug 1117603 from being backed out.
https://hg.mozilla.org/integration/mozilla-inbound/rev/5329cda711c8
Assignee | ||
Comment 12•10 years ago
|
||
(In reply to David Baron [:dbaron] ⏰UTC-7 from comment #11)
> Can this reland now that bug 1117603 stuck?
Yes! (I was just running it through try over the weekend and making sure bug 1117603 really stuck this time!)
https://hg.mozilla.org/integration/mozilla-inbound/rev/7edc16a9d48f
Try run:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=72968ef6f7ef
Flags: needinfo?(bbirtles)
Comment 13•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-firefox40:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in
before you can comment on or make changes to this bug.
Description
•