Augustin Trancart [:autra] Reporter
	Description • 9 years ago

[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)

	Patrick Brosset <:pbro>
	Comment 1 • 9 years ago

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.

	Patrick Brosset <:pbro>
	Comment 2 • 9 years ago

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.

	Brian Grinstead [:bgrins] Assignee
	Comment 3 • 9 years ago

(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

	Brian Grinstead [:bgrins] Assignee
	Comment 4 • 9 years ago

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

	Brian Grinstead [:bgrins] Assignee
	Comment 5 • 9 years ago

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

	Brian Grinstead [:bgrins] Assignee
	Comment 6 • 9 years ago

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

	Brian Grinstead [:bgrins] Assignee
	Comment 7 • 9 years ago

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

	Jordan Santell [:jsantell] [@jsantell]
	Comment 8 • 9 years ago

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

	Brian Grinstead [:bgrins] Assignee
	Comment 9 • 9 years ago

(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.

	Pulsebot
	Comment 10 • 9 years ago

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

	Brian Grinstead [:bgrins] Assignee
	Comment 11 • 9 years ago

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

	Brian Grinstead [:bgrins] Assignee
	Comment 12 • 9 years ago

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

	Patrick Brosset <:pbro>
	Comment 13 • 9 years ago

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).

	Patrick Brosset <:pbro>
	Comment 14 • 9 years ago

(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?

	Carsten Book [:Tomcat]
	Comment 15 • 9 years ago

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

	Augustin Trancart [:autra] Reporter
	Comment 16 • 9 years ago

VERIFIED FIXED on Firefox 44.0a1
Build ID: 20151002030204

Thanks a lot!