Closed Bug 1258476 Opened 4 years ago Closed 4 years ago
Total freeze when dragging selected text on Git
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.
4 years ago
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
FWIW, Bug 1216001 did not fix this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mats, what do you think?
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
FTR, here's a typical range. It ends in the white-space before the <td> on the next line.
Attachment #8742127 - Flags: review?(bzbarsky)
(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.
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.
3 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.