Closed Bug 186052 Opened 22 years ago Closed 21 years ago

crashes if I print a page with <INPUT type="image" align="right"> I know this is depracated, but still... it crashes every window I have open.

Categories

(Core :: Printing: Output, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jeff, Assigned: rods)

References

()

Details

(Keywords: crash, stackwanted)

Attachments

(3 files, 1 obsolete file)

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 I narrowed the problem down to the align= element, I have found a way around this using CSS, but there are probably other quirks which will cause this same crash when you try to print. Reproducible: Always Steps to Reproduce: 1. Create a document with a form 2. use an <INPUT TYPE="IMAGE"> to submit the form 3. print it before pressing the submit button. Actual Results: all the windows close, and the bug submission form comes up. Expected Results: the best thing would be for mozilla to interpret that html tag the best it can, by aligning it to the right, but if thats too much to ask, it should have recognized an html error and continued to run. Thanks mozilla hackers!
can you attach Talkback ID "mozilla/bin/components/talkback/talkback" or GDB stack trace ?
Keywords: crash, stackwanted
we need the talkback ID run mozilla/components/talkback/talkback see what the ID was for the talkback incident you sent in, and report that here.
I never submitted the talkback electronically, I saved it to a file instead because these computers dont have direct access to the internet. Isn't it all the same info? It may be worth noting that all these computers use nfsroot, they're diskless kiosks.
AFAIK, the talkback info itself is pretty useless.
I can't submit the talkback electronically, these computers dont have internet access. Try reproducing it yourself, print a page with <INPUT type="image" align="right"> I thought at first that STYLE="float: right" fixed the problem but I was wrong, including any sort of align attribute in the input tag doesn't work, I got around it by putting the INPUT in a table and aligning the td right. When you try to print an INPUT with alignment, it will print, but the image isn't on the page when it comes out of the printer, and the browser crashes immediatly after printing. Both align="right" and style="float: right" will display correctly in the browser, they just won't print correctly. these two crash the browser: <input type="image" src="page55_files/plainnext_01.gif" name="Continue" border="0" style="float: right"> <input type="image" src="page55_files/plainnext_01.gif" name="Continue" border="0" align="right"> this won't: <input type="image" src="page55_files/plainnext_01.gif" name="Continue" border="0">
FYI: This is only on Linux, on windows it doesn't crash.
Jeffrey, can you attach a testcase "Create a New Attachment" with the page that would crash Mozilla ? I cannot reproduce crash here with the attached testcase and Mozilla 20021226 on Linux.
Attachment #110204 - Attachment mime type: text/plain → text/html
Your test case didn't crash my mozilla, only this one. Maybe the input has to be inside tables or something.
I'm using redhat 8 with gnome.
Attachment #110204 - Attachment is obsolete: true
testcase from comment 9 doesn't crash my build 20021226 on Linux, no warning in console from a debug build. Do you crash with 1.3a or latest nightly build ? http://ftp.mozilla.org/pub/mozilla/nightly/latest
It's mozilla 1.2.1, I downloaded it as a stable release off the website. I'm printing with LPRng-3.8.9 I recently upgraded this system from redhat 7.2 to 8.0, by upgrading all the packages. The client kiosks are all using XFree86 to connect to the server, they have a fresh install of redhat 8.0 workstation. XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-72) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-11smp i686 [ELF] Build Host: daffy.perf.redhat.com Module Loader present OS Kernel: Linux version 2.4.20 (root@luke) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #6 Fri Dec 6 16:19:29 MST 2002 PF The clients boot from the network server with their own small filesystem, so one thing I worry about is one program clobbering another. Sometimes when the users don't shut down, they restart mozilla and it says their profile is currently in use, we either have to delete the lock file, or create a new profile until the old one times out. There have been times when the client didn't crash on the kiosks after printing that but I haven't figured out why, when I print from my windows Xserver, it won't crash. Is there something new about the way it prints? Older netscape browsers worked fine printing. I notice the screen resolution has something to do with the way the document comes out on the printer. The font server is running on the main server, the kiosks aren't running their own font server. What is in the electronic crash talkback data that can't be found in the file I posted? Is there any way to get it? Let me know if theres anything else I can do. I thought the GDB stack trace is the same data that's in the talkback file? I am attaching the last hundred lines or so strace prints before it crashes.
WFM, 2003-11-10-05 trunk Linux
WFM: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
Jeffrey, can you still reproduce this?
WFM, 2004-03-05-09 trunk Windows XP. WFM, 2004-02-20-08 trunk Linux. -> WORKSFORME
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: