Closed
Bug 804148
Opened 12 years ago
Closed 12 years ago
DomContentLoaded does not trigger CSS transitions
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
INVALID
People
(Reporter: t.tom, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 Safari/536.26.14
Steps to reproduce:
Start a transition as soon as the DOMContentLoaded event was fired.
Actual results:
The transition is never stared and the element is directly placed at the final position.
Expected results:
The page should have started the transition as soon as the DOMContentLoaded was fired.
Reporter | ||
Comment 1•12 years ago
|
||
Attachment #673866 -
Attachment mime type: text/plain → text/html
This is WFM in current nightly (19), can reproduce in release (16).
Whiteboard: DUPME
Disregard comment 2, I can only get it working intermittently in nightly (succeeded every time yesterday). So this is obviously not fixed
Whiteboard: DUPME
![]() |
||
Updated•12 years ago
|
Attachment #673867 -
Attachment mime type: text/plain → text/html
![]() |
||
Comment 4•12 years ago
|
||
Nightly linux-x86_64:
Doesn't work with either testcase (the text is partly outside of the page — transitions not supported?): 2011-02-28-03…2011-05-04-03
Confirmed: 2011-05-05-03….
https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-05-04+01&enddate=2011-05-05+04
OS: Mac OS X → All
Version: 13 Branch → Trunk
Comment 5•12 years ago
|
||
Confirmed with the attached test cases on:
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 (20121030030633)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
Updated•12 years ago
|
Component: Untriaged → Style System (CSS)
Product: Firefox → Core
![]() |
||
Comment 6•12 years ago
|
||
The behavior is correct per spec. DOMContentLoaded can easily fire before any layout has been done, in which case there is no computed style determination until _after_ the event, so there is never a "pre-change" state here.
This is the same as what you get if you create a new element, put it in the DOM, then immediately set its className (maybe even off a timeout). You might or might not get a transition depending on the race between the first time the style is computed and the className set.
This is, unfortunately, a known issue with the transitions spec. You can work around by explicitly computing the relevant style on the element before you try to start the transition....
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•