1258476 - Total freeze when dragging selected text on GitHub

Status: VERIFIED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Thomas Lange]

Attachment: Screencast.ogv

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160319124722

Steps to reproduce:

1. View source code on GitHub
2. Select some code
3. Drag it


Actual results:

Cursor state switches, Firefox freezes completely, 100 % CPU utilization


Expected results:

No freeze

Comment 1

[Thomas Lange]

Example link from the screencast:
https://github.com/mozilla/gecko-dev/blob/master/widget/ContentCache.cpp

Comment 2

[Thomas Lange]

Firefox can be unresponsive for minutes. Killing the process is the only option in this case (like in the screencast).

The bug occurs also with Firefox 46 and a clean profile.

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

Last good revision: 152ef25e89ae (2014-09-10)
First bad revision: 98ea98c8191a (2014-09-11)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=152ef25e89ae&tochange=98ea98c8191a

=> likely by Bug 739396
=> maybe dupe of/related to already filed and worked on Bug 1216001 (what has been backouted but yet not reopened?); didn't have time to profile/windbg this

Comment 4

[(mostly gone) XtC4UaLL [:xtc4uall]]

FWIW, Bug 1216001 did not fix this.

Comment 5

[Andrew Overholt [:overholt]]

Mats, what do you think?

Comment 6

[Mats Palmgren (inactive)]

The root of the problem is that the common ancestor for each range
is the table-group and PresShell::CreateRangePaintInfo creates
a display list for the frame of the common ancestor, which includes
pretty much the entire page here.  And we have one range per selected
line because all the <td>line number</td> have -moz-user-select:none.

Comment 7

[Mats Palmgren (inactive)]

Fixing bug 1245883 might also help some here.

Comment 8

[Mats Palmgren (inactive)]

Attachment: range

FTR, here's a typical range.  It ends in the white-space before the <td>
on the next line.

Comment 9

[Mats Palmgren (inactive)]

Attachment: fix

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6816a7eebfb7

Comment 10

[Mats Palmgren (inactive)]

(There's also an unrelated bug in the mouse cursor we create from the selection -
I filed this as bug 1265249.)

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8742127 [details] [diff] [review]
fix

I don't remember the display list setup well enough to review this effectively.  Timothy, can you take a look?

Comment 12

[Timothy Nikkel (:tnikkel)]

Comment on attachment 8742127 [details] [diff] [review]
fix

Shouldn't we move the BuildDisplayListForNode(startParent) call to before the for loop?

This will probably mean we can get into even weirder situations building displaylists and painting here than we could before. But we should probably just deal with those if they come up.

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/47cfd468f1a6

Comment 14

[Mats Palmgren (inactive)]

> Shouldn't we move the BuildDisplayListForNode(startParent) call to before the for loop?

Yes, I did so.  Good catch.

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/47cfd468f1a6

Comment 16

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

I reproduced this issue on 46.0b3 (20160321115535) using 
- Ubuntu 16.04 x64
- Windows 10 x64
- Mac OS X 10.11
Also, I confirm that the bug is resolved on 48.0b2 build1 (20160620091522) (verified across platforms). I didn't notice any misbehavior, except Bug 1265249.