Closed Bug 138436 Opened 23 years ago Closed 23 years ago

Changing text zoom freezes browser, system

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: mozbug1008.panua, Assigned: karnaze)

References

(
URL
)

Details

(Keywords: hang, regression, Whiteboard: [adt2]PATCH)

Attachments

(1 file)

patch to fix the bug
735 bytes, patch
alexsavulov
: review+
asa
: approval+
Details | Diff | Splinter Review
http://www.wincustomize.com/news_comments_full.asp?NewsID=765 When using text zoom in above page browser seems to halt and the whole system becomes unresponsive. Only way to correct situation is to close Mozilla from task list or taskbar --> close. 1. go to http://www.wincustomize.com/news_comments_full.asp?NewsID=765 2. try to change text size with view --> text zoom, or ctrl-+ expected beheaviour: text size should change what happens: Browser hungs. reprodusible: always
Summary: Suing text zoom freezes browser, system → Changing text zoom freezes browser, system
Seeing this problem with Win98, Moz 1.0 RC1, too. Changing text size with the mouse wheel has the same effect.
Severity: major → critical
Keywords: hang
the trunk build tested with 4-18 winXP doesn't seem to have this problem.. looks to be branch specific..
hmm... I didn't try the URL on that last comment, thrown off by the posts to this bug from mozillazine that text zoom was broken.. is why and its not that, it just freezes this kinda page. I just tested the URL with RC1 on WinXP, here and it does indeed freeze... I know that using the text zoom on text only pages with a lot of content is slow.. but never had it freeze.. it maybe that this page has a lot of objects/code that it has to parse to resize that text in time. I got it to freeze by just hitting Ctrl-+ I just found that if you let mozilla sit long enough (ie several minutes) it will resize the text.. and will return back to a usable state. By the time it took forme to think of this comment and write it down.. mozilla was back to working. If you play with mozilla while it is doing this, it makes the window lose its contents before coming back. The trunk build 4-18-03 is also affected. confirming: marking new.
Status: UNCONFIRMED → NEW
Ever confirmed: true
confirm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020418 after hitting the ctrl +, the mozilla freez, i waited for about 2min', and the the mozilla come back to life, but the text size didn't change, after clicking the "back" button (to return to this bug page) the text here was big, the ctrl+ effect here, but not on http://www.wincustomize.com/news_comments_full.asp?NewsID=765
-> Layout (?)
Assignee: Matti → attinasi
Component: Browser-General → Layout
QA Contact: imajes-qa → petersen
There's a recent similar bug for Linux. See bug 138427.
Attachment 80225 [details] to bug 138427 has a forced stack trace from ~10 seconds into the freeze (stack trace from 20020415 [6pm EST] CVS build of main branch). Confirm on 2002041617 nightly from 1.0.0 branch (Linux), as well.
*** Bug 138427 has been marked as a duplicate of this bug. ***
It's a recent regression which makes the TextZoom feature useless. Should definitely be fixed in 1.0.
Keywords: mozilla1.0, regression
OS: Windows 2000 → All
Hardware: PC → All
Text zoom is a critical feature for us. (We don't change text zoom on the fly, though). 2-minute UI lockups are no better than a crash; many/most users will simply kill the program. I'll try to get a jprof on this.
Blocks: 138000
Changing QA Contact
QA Contact: petersen → moied
adding nomination keyword. highly visible regression.
Keywords: nsbeta1
nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P1
Whiteboard: [adt2]
Target Milestone: --- → mozilla1.0
Taking the bug. I see the problem with a 4/25/2 win2k trunk build when doing ctl- on the url. It would be nice to know when this regressed and to have a reduced test case.
Assignee: attinasi → karnaze
Keywords: qawanted
Oldest version I have is Linux 2002041421 and I see this symptom with it. Also the URL can be just www.wincustomize.com Wincustomize fronpage doesn't take >2 minutes (with my W2k machine) to change text size but nearly 30 seconds, I have more powerfull linux machine that can affect the results also.
make it (as with my W2k machine)...
I see the problem on a 4/7/2 build but not on a 4/6/2 build. It looks like the patch in bug 128229 caused this regression, but since that patch looks like the right thing to do, it may have just exposed another bug. I need to look further.
Status: NEW → ASSIGNED
This bug is a regression caused by bug 128229. The patch is a low risk one line change that prevents redundantly reflowing an auto-layout (most tables are auto-layout) table's children with a style change reflow reason. It removes the feeling of a hang on the url and should speed up all style change reflows involving auto-layout tables.
Keywords: adt1.0.0, approval
Whiteboard: [adt2] → [adt2]PATCH
Comment on attachment 81219 [details] [diff] [review] patch to fix the bug sr=attinasi
Attachment #81219 - Flags: superreview+
Comment on attachment 81219 [details] [diff] [review] patch to fix the bug r= alexsavulov very gut!
Attachment #81219 - Flags: superreview+ → review+
Comment on attachment 81219 [details] [diff] [review] patch to fix the bug a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #81219 - Flags: approval+
Adding adt1.0.0+ Please check into the branch as soon as possible and add the fixed1.0.0 keyword.
Keywords: adt1.0.0 → adt1.0.0+
The patch on the trunk seems to have been applied at about 8:54 today and the 2002042708 build was posted around 12:45. Should this fix have gotten into that build?...becuase I am still seeing the freeze described in comment 0. I'll test again tomorrow. Jake
Tested on http://www.wincustomize.com/news_comments_full.asp?NewsID=765 Works fine. I have: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+) Gecko/20020428 2002-04-28-08 Good work :-)
Checked into m1.0 branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
*** Bug 140907 has been marked as a duplicate of this bug. ***
*** Bug 143279 has been marked as a duplicate of this bug. ***
*** Bug 135033 has been marked as a duplicate of this bug. ***
verified fixed with branch build 20020523 on winxp, adding KW:verified1.0.0 and marking verified.
Status: RESOLVED → VERIFIED
Keywords: verified1.0.0
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: