Closed Bug 617008 Opened 9 years ago Closed 6 years ago
Long render time for paragraph containing word with lots of ­<wbr>. Exponential with word size?
112.68 KB, text/html
6.47 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv:220.127.116.11) Gecko/2009030117 Firefox/3.0.6 Build Identifier: Firefox 3.6.12 I constructed a long paragraph <p> in an HTML document containing only one word with frequent occurences of ­<wbr> to make it line-break at certain positions. With the paragraph <p>01234567890123456789­<wbr>01234567890123456789­<wbr> ... </p> in a very simple HTML document it takes a long time to render as the paragraph reaches about 100KB in size. Larger paragraphs seem to take exponentially more time to render. Reproducible: Always Steps to Reproduce: 1. Construct HTML paragraph with an approx 100KB word containing regular occurences of ­<wbr> 2. View document in Firefox 3.6.12 (and other versions?) 3. Wait for 15 seconds for page to render. Actual Results: 15 seconds to render 100KB document on Firefox 3.6.12 for Windows. Think it was exponential for larger documents. Also tried it on a different operating system with the same results. Expected Results: Quick render, linear with paragraph size. IE 6 renders the same document instantly.
Don't open this if you don't want to wait a long time for it to render.
Can confirm the issue on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0E) ID:20101026210630
Component: General → Layout: Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
Version: unspecified → 1.9.2 Branch
Status: UNCONFIRMED → NEW
Ever confirmed: true
The shy failed to render hyphen because probably <wbr> elements cause line-break. This is not unexpected behavior for web page authors.
> This is not unexpected behavior for web page authors. This *is* unexpected behavior.
Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0 Confirming bug in recent nightly
Version: 1.9.2 Branch → Trunk
Profiling revealed that we're spending an excessive amount of time creating a rendering context from within PropertyProvider::GetHyphenWidth, even though in the (common) case where the font group has already cached the hyphen width internally, we won't actually need that context for anything. By refactoring so that the context is created only if actually needed, the total time spent in DoReflow() for this testcase in my local (opt) build is reduced from 5.1 seconds to 2.7s.
Attachment #8399123 - Flags: review?(roc)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Attachment #8399123 - Flags: review?(roc) → review+
Target Milestone: --- → mozilla31
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
I wouldn't call it "fixed" but at least there is a decrease from something like 46 to 28 seconds on my old computer.
You need to log in before you can comment on or make changes to this bug.