Save Page As Text Fails, Pegs CPU, Brings System to Its Knees

VERIFIED DUPLICATE of bug 141455

Status

Core Graveyard
File Handling
--
major
VERIFIED DUPLICATE of bug 141455
16 years ago
2 years ago

People

(Reporter: Felix Miata, Assigned: mkaply)

Tracking

({hang, pp})

Trunk
x86
OS/2
hang, pp

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
2002050108 OS/2 trunk

To reproduce:
1-Open any web page (I use Google)
2-Open a new tab
3-Open a page (I use an ASP search result)
4-Select 'File -> Save Page As'
5-In filepicker (I run XFile) choose type "text file" and a suitable filename
6-Select "OK"

Actual results:
1-CPU meter pegs
2-Mozilla is no longer responsive
3-File saving dialog does not open
4-System speed seems to drop to 0.1 Mhz
5-Mozilla must be killed to get use of system back
6-Zero byte file created

Expected results:
1-File saving dialog opens
2-File is saved
3-Mozilla remains usable
4-System response remains normal without killing Mozilla

Additional information:
If I instead choose "web page, HTML only", the file is saved, but the download
manager history window comes up instead of the normal saving progress dialog.
Text file save fails the same on both HPFS and FAT16.
The download manager thing is a separate issue (that's the new default behavior).

I cannot reproduce this on Linux... Could you please list the exact urls you are
using?
(Reporter)

Comment 2

16 years ago
How do you change from the new default behavior to the old behavior?

URL's don't matter, but these suit the purpose:
Tab 1 - http://www.google.com/
Tab 2 - 
     Initial - http://us.imdb.com/search
     Results page to save - http://us.imdb.com/Name?Dunst,+Kirsten
(Assignee)

Comment 3

16 years ago
Confirm on OS/2. 

Checking.
Assignee: law → mkaply
Status: UNCONFIRMED → NEW
Ever confirmed: true
> How do you change from the new default behavior to the old behavior?

See Bug 121324, comment 9.  The UI is bug 141278 or bug 132440.

This looks like it's OS/2-only....
Keywords: pp
(Assignee)

Comment 5

16 years ago
Broke between 29th and 30th.

My file picker changes went in there, but they also went into the branch and the 
branch is not hanging.

I'm going to try backing out my file picker changes and see what happens.
(Assignee)

Comment 6

16 years ago
hangs without my filepicker changes as well...
(Reporter)

Comment 7

16 years ago
Worksforme in 2002050208 OS/2 trunk.
(Reporter)

Comment 8

16 years ago
In prefs.js I put user_pref("browser.downloadmanager.behavior", 1);. I got all
the (preferred) old behavior back now.

Updated

16 years ago
Keywords: hang
(Assignee)

Comment 9

16 years ago
Man I love to see things like this fixed with no help from me.

I worry that Os/2 is horribly broke when I see this stuff.

*** This bug has been marked as a duplicate of 141455 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 10

16 years ago
Out of extreme curiosity, how did you make the connection to bug 141455? Lack of
any other checkins that could have produced a fix? Any connection between file
save hang and select text hang beyond the word hang seems rather tenuous.
(Assignee)

Comment 11

16 years ago
when I looked at the checkins that could have caused this, I noticed a checkin 
to nsPlainTextSerializer.

nsPlainTextSerializer is the code that converts files to TXT.

Then when I looked at the time frame in which the bug was fixed, I noticed 
another checkin to nsPlainTextSerializer that specifically related to fixing a 
bug in the code I had seen checked in before, and it specifically referenced a 
hang.

So I concluded that what you were seeing was just another manifestation of that 
bug.
marking verified as a duplicate.

if you decide to reopen this bug, please clarify why.

search string for bugspam removal: SalviaGuaranitica
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.