[CLOSED] Fix #10142. LiveDev2: Firefox highlight does not have fade-away effect.

[core-ai-bot]

Issue by busykai
Thursday Dec 11, 2014 at 18:34 GMT
Originally opened as adobe/brackets#10151

---

Fixes #10142.

Wait a little longer for the highlight element to take it's initial state. If
the element is not yet in its initial state, the transition does not happen. It
seems like on Firefox/Gecko it takes longer than on Chrome/Webkit.

This is a quote from MDN article on subject:

Care should also be taken when using a transition immediately after adding the element to the DOM using .appendChild() or removing its display: none; property. This is seen as if the initial state had never occurred and the element was always in its final state. The easy way to overcome this limitation is to apply a window.setTimeout() of a handful of milliseconds before changing the CSS property you intend to transition to.

CC:@dangoor,@redmunds

---

busykai included the following code: https://github.com/adobe/brackets/pull/10151/commits

[core-ai-bot]

Comment by cheesypoof
Friday Dec 12, 2014 at 16:03 GMT

---

I haven't looked at this issue first-hand, but the description reminded me of an item in the Firefox 34 developer release notes.

Fixed starting of CSS transitions that start together with changes to display, position, overflow, and similar properties (bug 887541)

Do you think that fix could be relevant to this issue?

[core-ai-bot]

Comment by busykai
Friday Dec 12, 2014 at 17:40 GMT

---

@cheesypoof, thanks for the reference. I'll look into it to see if our code could be reorganized. From the looks of it, it sounds like that FF does not do appendChild synchronously hence requiring a tangible wait period (well, 20ms is not perceivable, but still longer than just yielding). The issue was still reproducible with the Aurora latest versions (~FF 36).

[core-ai-bot]

Comment by redmunds
Wednesday Jan 14, 2015 at 22:40 GMT

---

Much better! Thanks. Merging.