Pale Moon 27 alpha 2 hang report Topic is solved

[win7-7]

Tycho had hang moment ago. It eventually recovered from hang but that hang was quite long. This seems to happen always when you try to copy long page of text ( either with pressing mouse button down and scrolling text page down or with ctrl +a) ( Github can cause this hang when copying long amount of text). This doesn't happen in the stable version of Pale Moon so it is regression in the codebase that causes hang.

Hang report from WhatIsHang:

http://pastebin.com/AM6jwJW4

[win7-7]

First bad Firefox version/ codebase that causes this hang: Firefox 35

First "good" Firefox version/ codebase: Firefox 47 but it is still not so smooth, it just doesn't hang anymore, more ideal solution to revert regression whatever caused this at first place in Firefox 35.

Firefox 47 had this fix: https://bugzilla.mozilla.org/show_bug.cgi?id=1216001

https://hg.mozilla.org/integration/mozi ... 97d3da7374,

however as noted earlier scrolling while pressing mouse button down and ctrl + a is still not as smooth as it was before regression of Firefox 35, so fix only fixes hang not performance regression that is still present in Firefox 47.

I will edit this post if I find specific bug related to this regression from bugzilla. I haven't had time to look specific yet but I did find regression range with Mozregression.

Still well working build of Firefox 35 ( Mozilla Central) was 10.9.2014

First bad build of Firefox 35 ( Mozilla Central) was 11.9.2014

https://hg.mozilla.org/mozilla-central/ ... ea98c8191a There is changelog from 10.9.2014 to 11.9.2014. I haven't found yet what is exactly responsible for regression in Firefox 35.

[Moonchild]

Can you add exact steps to reproduce?

[win7-7]

example url: https://github.com/MoonchildProductions ... rowser.xml

Press down the mouse button and scroll page and text , it will be very slow and has also sometimes hanged browser even in that part and if you press ctrl + a it will always hang browser.

Also any long enough page could likely reproduce this.

Another example: https://github.com/MoonchildProductions ... rowser.css

This can cause large slow down but not hang because this is not as long page as tabbrowser.xml is.

One more example: https://github.com/MoonchildProductions ... rowser.xul

But only first example can cause hang because page need to be long enough to cause hang. Other examples cause still large slow down.

[Moonchild]

Looks like the regressing bug is bug #739396 which interacts poorly with the changes made in Firefox 11 in bug #619273.

[Moonchild]

OK, I figured out what the issue is, specifically, and why Firefox 47 is still affected.
The problem with the listed pages is that they have a lot of display elements with -moz-user-select: none; in them.
The regressing bug splits the selection up into only those ranges that allow user-selection - and with generated content that has a lot of non-selectable display elements, it causes a very large array of selection segments that have to be run through for each change of display (because of text styling for selected text).
Firefox 47/48 improves this by caching and using faster lookups, but the bottom line remains that selected ranges like this are still huge arrays instead of single selections and can't be handled any faster, even on fast processors.

The dilemma is here: the later behavior is more according to draft spec for this keyword (CSS4 draft) by more accurately visually selecting the text, but obviously gets a huge perf hit by doing this.

EDIT: Considering the bug is only visual, and what is actually copied to clipboard and the likes is correct and according to spec, a change to the layout engine to avoid this performance regression is the better choice, until such time as a better solution is available.

[Moonchild]

This has been solved in Tycho.