1210375 - Cannot unfold a html tag in the inspector

Status: VERIFIED FIXED

(DevTools :: Inspector, defect)

Description

[Augustin Trancart [:autra]]

[steps]
- download latest nightly and launch it
- navigate to any webpage
- open the devtools 
- open the inspector tab
- try to unfold a folded html tag

[Expected]
The html tag unfold

[actual]
I cannot unfold the html tag. From time to time, I manage to unfold it by double-clicking on it (or clicking 2 times with like half a second between the 2 clicks)

Comment 1

[Patrick Brosset <:pbro>]

I'm not seeing any errors in the console.
Really surprised this passed our tests ...

The node expands for a very short amount of time, and then closes again, and its background flashes orange as if there was a DOM mutation.

Comment 2

[Patrick Brosset <:pbro>]

My local build was done from fx-team, which I updated yesterday, so this is only in today's nightly.
The only thing that seems remotely related is bug 1209342.

Comment 3

[Brian Grinstead [:bgrins]]

(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #2)
> My local build was done from fx-team, which I updated yesterday, so this is
> only in today's nightly.
> The only thing that seems remotely related is bug 1209342.

A backout of bug 1209342 locally doesn't fix the problem

Comment 4

[Brian Grinstead [:bgrins]]

This is because of the GRAB_DELAY change in Bug 1208544.  I put in a fix to limit the chance of an intermittent being introduced as mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1034110#c47.

There's a typo where I set this.GRAB_DELAY instead of this.markup.GRAB_DELAY and since all the tests passed I missed it :(.  I'll attach a fix here

Comment 5

[Brian Grinstead [:bgrins]]

Attachment: MozReview Request: Bug 1210375 - Use correct GRAB_DELAY in the markup view;r=pbrosset

Bug 1210375 - Use correct GRAB_DELAY in the markup view;r=pbrosset

Comment 6

[Brian Grinstead [:bgrins]]

This includes a test case that will fail if something like this happens again.  Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9dde8718fdd7

Comment 7

[Brian Grinstead [:bgrins]]

Comment on attachment 8668475 [details]
MozReview Request: Bug 1210375 - Use correct GRAB_DELAY in the markup view;r=pbrosset

Redirecting review, since we should get a fix for this out in time for tomorrow's nightly

Comment 8

[Jordan Santell [:jsantell] [@jsantell]]

Comment on attachment 8668475 [details]
MozReview Request: Bug 1210375 - Use correct GRAB_DELAY in the markup view;r=pbrosset

https://reviewboard.mozilla.org/r/20969/#review18863

::: devtools/client/markupview/test/browser_markupview_dragdrop_isDragging.js:31
(Diff revision 1)
> +  yield wait(10);

Is GRAB_DELAY 400ms here? Shouldn't the wait be atleast that? I'd use polling here to reduce potential intermittents, seems like we'd run into that in this test

Comment 9

[Brian Grinstead [:bgrins]]

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #8)
> Comment on attachment 8668475 [details]
> MozReview Request: Bug 1210375 - Use correct GRAB_DELAY in the markup
> view;r=pbrosset
> 
> https://reviewboard.mozilla.org/r/20969/#review18863
> 
> :::
> devtools/client/markupview/test/browser_markupview_dragdrop_isDragging.js:31
> (Diff revision 1)
> > +  yield wait(10);
> 
> Is GRAB_DELAY 400ms here? Shouldn't the wait be atleast that? I'd use
> polling here to reduce potential intermittents, seems like we'd run into
> that in this test

It is 400ms.  The bug that was introduced was that the drag started as a result of setTimeout(() => {}, undefined) so it was starting the drag nearly immediately.  No tests caught it because none were checking to make sure the drag *hadn't* started, they were just making sure it had after 401ms.  So this new check makes sure it hasn't started after a short delay.

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/df3fb2045c1c

Comment 11

[Brian Grinstead [:bgrins]]

Comment on attachment 8668475 [details]
MozReview Request: Bug 1210375 - Use correct GRAB_DELAY in the markup view;r=pbrosset

(In reply to Pulsebot from comment #10)
> https://hg.mozilla.org/integration/fx-team/rev/df3fb2045c1c

Ah forgot to update the reviewer before pushing - sorry Patrick for the false r=pbrosset

Comment 12

[Brian Grinstead [:bgrins]]

Augustin, can you please confirm tomorrow that the nightly build has been updated and is working as you expect?

Comment 13

[Patrick Brosset <:pbro>]

Tested on today's nightly, the problem seems to be fixed.
I'm wondering if bug 1210507 (also filed yesterday) is related too. The effect is the same, the cause is different: try to double click an attribute (or the new attribute field at the end of a MarkupContainer line).

Comment 14

[Patrick Brosset <:pbro>]

(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #13)
> Tested on today's nightly, the problem seems to be fixed.
> I'm wondering if bug 1210507 (also filed yesterday) is related too. The
> effect is the same, the cause is different: try to double click an attribute
> (or the new attribute field at the end of a MarkupContainer line).
My bad, I was testing on the nightly build from october 1st. Tested again on a local fx-team build (done today), and both problems are gone. So bug 1210507 is most likely a duplicate. Brian, can you confirm and close as dupe?

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/df3fb2045c1c

Comment 16

[Augustin Trancart [:autra]]

VERIFIED FIXED on Firefox 44.0a1
Build ID: 20151002030204

Thanks a lot!