[CLOSED] FindReplace tests fail when run as part of the unit test suite

[core-ai-bot]

Issue by dangoor
Friday Sep 06, 2013 at 14:21 GMT
Originally opened as adobe/brackets#5094

---

On my Mac, I see a consistent failure of 11 FindReplace unit tests only when the whole unit test suite is run. If FindReplace is run by itself, the tests all pass.

[core-ai-bot]

Comment by jasonsanjose
Thursday Sep 12, 2013 at 21:47 GMT

---

cc@njx

I found that the test should Find Next after search bar closed, including wraparound is waiting for the modal bar to disappear in waitsForSearchBarClose but it never does.

The reason it was never removed from the DOM is because ModalBar waits for webkitTransitionEnd on the modal-bar-hide animation before removing it from the DOM. This doesn't happen because the actual style rule defined in brackets.less isn't actually included in the SpecRunner.html.

I'm not sure how these tests are passing on the build machine at all. That's just weird.

Anyhow, just dropping in brackets.less into SpecRunner.html won't work since that will break the runner UI.

[core-ai-bot]

Comment by njx
Thursday Sep 12, 2013 at 21:50 GMT

---

It's weird because I haven't seen that test fail when running the whole suite. But the cause you mentioned makes sense. Assigning to me.

[core-ai-bot]

Comment by njx
Friday Sep 13, 2013 at 01:07 GMT

---

Ah, I can see some failures if I run every test (not just the ones in the "Unit" list), although I only see 3. I don't understand why it doesn't always fail.

[core-ai-bot]

Comment by njx
Friday Sep 13, 2013 at 01:19 GMT

---

Aha! It turns out that (1) webkitTransitionEnd bubbles (which is weird) and (2) in Bootstrap, input controls have various transitions set on them which fire on focus change; the input field in the Find bar appears to be the one triggering the transition end. That still doesn't explain why we sometimes get the event and sometimes don't, but it at least explains why it often doesn't fail.

(As an aside, it seems like our focus event in Brackets doesn't have the transition, so we get "lucky" that we don't accidentally respond to a transitionEnd event. The lesson is probably that we should always be checking the target of a transitionEnd to make sure it's the thing we think is transitioning.)

Haven't figured out the best way to fix this yet. We've had at least one other case where not having the "real" CSS when running tests has bitten us (in that case, it was that we had a class where Bootstrap set it to display: block when we set it to display: none). In general, in cases where CSS has real effects on the functionality that we test for (e.g. whether something is visible or not, or when functionality depends on a transition), we're susceptible to this issue.

[core-ai-bot]

Comment by njx
Friday Sep 13, 2013 at 01:34 GMT

---

Adding to this sprint.

[core-ai-bot]

Comment by redmunds
Friday Sep 13, 2013 at 15:45 GMT

---

Is the problem related to the undesired transitions after clicking "Yes" or "No" buttons? If so, then maybe fixing adobe/brackets#5168 will also fix the bugs.

[core-ai-bot]

Comment by njx
Friday Sep 13, 2013 at 16:33 GMT

---

No, it's an issue with any transition, not just those.

[core-ai-bot]

Comment by redmunds
Tuesday Sep 17, 2013 at 15:03 GMT

---

Not sure when@dangoor will be back, so proactively closing this one.