hang on http://www.festival-lumiere.org/ with additional style

RESOLVED INVALID

Status

()

Core
CSS Parsing and Computation
--
critical
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: Vincent Lefevre, Unassigned)

Tracking

({hang, testcase})

39 Branch
hang, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8646030 [details]
hang-ff39.tar.xz

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

Steps to reproduce:

0. Unarchive the attached test case (it contains a simple HTML file with 2 Javascript scripts and a CSS file).
1. Start Firefox in safe mode with a fresh profile.
2. Open the HTML file.

Alternatively, instead of the simple test case, add "a { font-size: inherit !important }" in the global styles (I use the Stylish extension), and open http://www.festival-lumiere.org/

This is how I found the problem. Then I saved this page (Web Page, complete) and simplified (I didn't touch the two scripts that were necessary).


Actual results:

Firefox hangs for several seconds, then a dialog box "Warning: Unresponsive script - A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue." appears.


Expected results:

Firefox shouldn't hang.
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1081743
Component: General → CSS Parsing and Computation

Updated

3 years ago
Severity: normal → critical
Keywords: hang, testcase
> Firefox shouldn't hang.

The page has script running an infinite loop.  Specifically, the resizeMenu function it calls onload has a loop like this:

        while($last.offset().top != $first.offset().top) {
            var $anchor = $lis.children('a, span.link');
            $anchor.css('font-size', (parseInt($anchor.css('font-size')) - 1)+'px');
        }

Now in your minimal testcase, $anchor doesn't contain any nodes so the loop body is a no-op, so the loop condition is never satisfied.  And on the original page, if you have a style that forces the font-size with "!important" the second line of the loop body will never change the font-size so the loop condition will never be satisfied.

So this is basically about what Firefox should do with this JS:

  while (true);

What we do is show the slow script dialog.  Seems right to me.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
(Reporter)

Comment 3

3 years ago
There are actually two problems:

1. The fact that there is a no-op loop. It seems that my minimal testcase introduced this loop (because I removed lots of things from the page). The question is whether this is also true (for another reason) for the real page when I use "a { font-size: inherit !important }". Probably since if I understand correctly, the "a { font-size: inherit !important }" would also make the $anchor.css('font-size', (parseInt($anchor.css('font-size')) - 1)+'px') no-op.

2. Is this a reason to make the *whole* UI hang (not just the page rendering)?
(Reporter)

Comment 4

3 years ago
Note: I've just noticed that the script seems to be fixed on http://www.festival-lumiere.org/ (I no longer get a freeze). I'm still wondering about problem 2, since the problem can occur on other web sites. Said otherwise, is it OK that a web site can make the whole Firefox UI hang for several seconds? IMHO, the UI should always be responsive, in particular when there is a video playing.
> The question is whether this is also true (for another reason) for the real page

Yes, because the !important rule introduced overrides the page styles.

> 2. Is this a reason to make the *whole* UI hang (not just the page rendering)?

This is what e10s aims to fix, yes?
(Reporter)

Comment 6

3 years ago
(In reply to Boris Zbarsky [:bz] from comment #5)
> This is what e10s aims to fix, yes?

It will probably fix this. I thought that multi-threading was enough to avoid UI hang.
It would be, but it has all the same issues as e10s in terms of addon compat and UI changes needed, plus worse memory safety properties...
You need to log in before you can comment on or make changes to this bug.