Very slow text input if HTML body specifies background url via CSS

RESOLVED FIXED

Status

()

Core
Graphics
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: fpierfed@gmail.com, Unassigned)

Tracking

Trunk
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.9a6pre) Gecko/20070606 Camino/2.0a1pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.9a6pre) Gecko/20070606 Camino/2.0a1pre

Entering text in form text input areas (both textarea and input tags) on pages that specify a background URL via CSS:

<body style='background: url("http://wiki.couchsurfing.com/wiki/images/4/4c/New-map.jpg");'>

is extremely slow. Removing the style element solves the problem.

Reproducible: Always

Steps to Reproduce:
1. Load the page.
2. Enter text in the textarea field.
Actual Results:  
Text input is very slow.

Expected Results:  
Text input is fast.

Example page that demonstrates the issue:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <meta http-equiv="content-type" content="text/html">
  <title>Test</title>
</head>
<body style='background: url("http://wiki.couchsurfing.com/wiki/images/4/4c/New-map.jpg");'>
  <form action="/email.html" method="post">
    <textarea name="emailbody" cols="68" rows="22"></textarea>
  </form>
</body>
</html>

Comment 1

11 years ago
How's the performance in trunk Firefox?
(Reporter)

Comment 2

11 years ago
Good question! It turns out that (on the firefox-3.0pre6 nightly from today) the performance is just as bad. 

The interesting thing is that the text entering speed is fine for the fraction of a second that it takes to download the background image. Then it slows down to a crawl.

Comment 3

11 years ago
That background image is huge (1072X2000px). 
I guess it is the same underlying issue as the very slow scrolling with those huge background images (bug 364221).

And yeah, typing in that test case (I'll attach it in a moment) is *slow* (feels like one of those old typewriters). Both Camino trunk and Minefield.

I haven't seen any previous mention of this, confirming.
Component: HTML Form Controls → GFX: Thebes
Product: Camino → Core
QA Contact: form.controls → thebes
Version: unspecified → Trunk

Updated

11 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

11 years ago
Created attachment 267779 [details]
test case from comment 0

Comment 5

11 years ago
Is this maybe just a dupe of that bug, then? It seems like while the symptoms may be slightly different, the fix would likely be the same.
(In reply to comment #5)
> Is this maybe just a dupe of that bug, then? It seems like while the symptoms
> may be slightly different, the fix would likely be the same.

Then it wouldn't be the same bug. Just because a fix resolves two bugs instead of just one, doesn't mean one bug is a dupe of another. That's why we have dependencies in bugzilla.

Comment 7

11 years ago
Right, but what I'm saying is "giant background image makes performance suck" is really the same bug for all values of "performance".

cl

Comment 8

11 years ago
It is not really a dupe.
If I 'un-aqua-fy' the textarea by applying border/padding/color in the stylesheet, typing speed returns to normal - or at least a reasonable speed, I'm slow at typing.
So this is a regression from the new form widgets, or partly a regression from them?

Comment 10

11 years ago
Testing on a home made Camino build after the Cairo 1.4.8 checkin. The performance is back to normal.
I see the same performance improvement with the testcase in bug 364221.

Updated

11 years ago
Duplicate of this bug: 384231
Depends on: 383960
(Reporter)

Comment 12

11 years ago
With the nightly build I downloaded today (Aug. 6th, 2007) the issue seems fixed. Can anybody else confirm this?

Thanks!
Francesco

Comment 13

11 years ago
(In reply to comment #12)
> With the nightly build I downloaded today (Aug. 6th, 2007) the issue seems
> fixed. Can anybody else confirm this?

According to comment 10, the issue was fixed almost two months ago. Is the 06 Aug 2007 build the first build in which you see the improvement?

cl

Comment 14

11 years ago
No, in comment 10, I had made a test when Cairo 1.4.8 was briefly checked in (and then backed out). See bug 383960.
Now that Cairo 1.5.10 has landed (landed at 2007-08-01 23:58), the test case works correctly.
I think this bug can be resolved: fixed.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 15

11 years ago
Oh, right, forgot about the backout.

Whoever verifies this should make sure that the first nightly after the 1.5.10 landing did indeed fix the bug.

cl
(Reporter)

Comment 16

11 years ago
Seems to me that the nightly from 2007-08-02 (trunk) is the first one to fix the problem.
You need to log in before you can comment on or make changes to this bug.