Closed Bug 1258476 Opened 4 years ago Closed 4 years ago

Total freeze when dragging selected text on GitHub

Categories

(Core :: Drag and Drop, defect, major)

35 Branch
x86_64
All
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla48
Tracking Status
firefox48 --- verified

People

(Reporter: thomas-lange2, Assigned: mats)

References

(Depends on 1 open bug, )

Details

(Keywords: hang, perf, regression, Whiteboard: btpp-followup-2016-04-21)

Attachments

(3 files)

Attached video 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
Example link from the screencast:
https://github.com/mozilla/gecko-dev/blob/master/widget/ContentCache.cpp
Severity: normal → major
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
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.
Component: Untriaged → Drag and Drop
Product: Firefox → Core
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
Blocks: 739396
Keywords: hang, perf, regression
OS: Linux → All
Whiteboard: [dupeme]
Version: 45 Branch → 11 Branch
Version: 11 Branch → 35 Branch
FWIW, Bug 1216001 did not fix this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [dupeme]
Mats, what do you think?
Flags: needinfo?(mats)
Whiteboard: btpp-followup-2016-04-21
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.
Assignee: nobody → mats
Flags: needinfo?(mats)
Fixing bug 1245883 might also help some here.
Depends on: 1245883
Attached file range
FTR, here's a typical range.  It ends in the white-space before the <td>
on the next line.
(There's also an unrelated bug in the mouse cursor we create from the selection -
I filed this as bug 1265249.)
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?
Attachment #8742127 - Flags: review?(bzbarsky) → review?(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.
Attachment #8742127 - Flags: review?(tnikkel) → review+
> Shouldn't we move the BuildDisplayListForNode(startParent) call to before the for loop?

Yes, I did so.  Good catch.
https://hg.mozilla.org/mozilla-central/rev/47cfd468f1a6
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
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.
You need to log in before you can comment on or make changes to this bug.