Closed Bug 270456 Opened 21 years ago Closed 19 years ago

Print preview generates a general protection fault.

Categories

(Core :: Print Preview, defect)

1.7 Branch
x86
Windows 98
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mmarcus, Unassigned)

References

()

Details

(Keywords: crash, stackwanted)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 I tried to do a print preview of our web site, http://www.observatoryscope.com/, and got a crash. Other frames sites seem to work OK. Our site, however, uses a lot of frames for effects/formatting. Another possibility is the use of -moz-opacity in our site wide cascading style sheet for any elements with the class of bodytextfog. Computer OS which generated the crash is Windows98 original with all updates. Here's the copy&paste of Window's crash box: FIREFOX caused a general protection fault in module <unknown> at 0000:0000b180. Registers: EAX=00000f21 CS=63b7 EIP=0000b180 EFLGS=00000246 EBX=0000fbff SS=6eaf ESP=0000b16e EBP=0000b22e ECX=00000056 DS=0000 ESI=0000c000 FS=0000 EDX=00000f01 ES=0000 EDI=00000000 GS=0000 Bytes at CS:EIP: 8a 25 8a c7 32 c4 22 c6 32 c4 aa 0a d2 75 01 cb Stack dump: 65472649 6eafb262 00000001 f48aa004 258a01b2 c432c78a c432c622 75d20aaa d68bcb01 258aece3 c432c78a c432c322 ebf3e2aa e1d000ed 873b00c9 30800062 Reproducible: Always Steps to Reproduce: 1. Site specific; go to http://www.observatoryscope.com. 2. In Firefox, select File>Print Preview. 3. Watch Firefox crash in module <unknown>. Actual Results: Firefox crashed! Expected Results: Preview of the site before printing the page. I haven't installed any themes. I specifically did not install Talkback since I have had problems with Talkback crashing with previous versions of Navigator or Netscape. FIREFOX caused a general protection fault in module <unknown> at 0000:0000b180. Registers: EAX=00000f21 CS=63b7 EIP=0000b180 EFLGS=00000246 EBX=0000fbff SS=6eaf ESP=0000b16e EBP=0000b22e ECX=00000056 DS=0000 ESI=0000c000 FS=0000 EDX=00000f01 ES=0000 EDI=00000000 GS=0000 Bytes at CS:EIP: 8a 25 8a c7 32 c4 22 c6 32 c4 aa 0a d2 75 01 cb Stack dump: 65472649 6eafb262 00000001 f48aa004 258a01b2 c432c78a c432c622 75d20aaa d68bcb01 258aece3 c432c78a c432c322 ebf3e2aa e1d000ed 873b00c9 30800062
Keywords: crash
wfm Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040909 Firefox/0.9.1+ please crash with talkback.
Keywords: stackwanted
Installed Talkback and made sure it was running prior to launching Firefox. Talkback doesn't even catch the crash since it is in module <unknown>. I rebooted after the crash and restarted Talkback just to be sure that a log for the crash didn't show up. Going to run a separate trace program to find the actual cause of the crash.
Posted attachment, SPOOL32.zip of calls by Firefox and subsequent crash in SPOOL32.EXE when trying to do a print preview of www.observatoryscope.com. The text file within the zip was generated by Dependency Walker, a utility written by a senior Microsoft programmer for tracing bugs within programs. I wanted to post a zip of all the calls made by Firefox to SPOOL32.EXE, but even the zip exceeds the 300kb limit for posted attachments.
that dependency walker output isn't useful, i'm not sure i'd have much use for the complete one, i suppose i might, if you can visit irc.mozilla.org and ask for timeless, someone should be able to help you find me. also, we really need to get talkback working, so while you're on irc, ask someone to help you verify that talkback is working, and if it isn't to help you get it working. note that we do assert a lot while print previewing your page, ASSERTION: aContent1 must not be null: 'aContent1', file r:/mozilla/layout/base/src/nsLayoutUtils.cpp, line 242 ASSERTION: aContent2 must not be null: 'aContent2', file r:/mozilla/layout/base/src/nsLayoutUtils.cpp, line 243 ###!!! ASSERTION: bad geometric parent: 'mFrames.ContainsFrame(aNextInFlow)', file r:/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 1091 ###!!! ASSERTION: intial reflow not called: 'HadInitialReflow()', file r:/mozilla/layout/html/table/src/nsTableFrame.cpp, line 1954 ###!!! ASSERTION: data loss - incomplete row needed more height than available, on top of page: 'rowMetrics.height <= rowReflowState.availableHeight', file r:/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp, line 1045
Component: Menus → General
QA Contact: bugzilla → firefox.general
the url is not reachable
This bug is partially resolved in Firefox 1.0.6. in that elements with transparency (-moz-opacity) are no longer rendered at all in either Print Preview or when printing. This prevents the crash in SPOOL32.EXE which can't handle transparency. There are two possible solutions to fully resolve this bug: 1. Ignore (strip) the -moz-opacity style and render the element with full opacity, thus allowing the element to render in Print Preview or when printing. This is the crude yet best solution since other styles combined with opacity (such as float) couldn't possibly cause problems if the opacity is stripped when printing. I like this solution the best; I'll explain why later. 2. Create a subroutine in the print rendering engine which creates a virtual example of the transparent element after the background and the transparent element have been merged, thereby producing a virtual element which "seems" to be transparent but really is not. This approach requires that the virtual element be created after taking into account the resized dimensions of the entire document and the possible change in position or movement of the transparent element relative to the underlying background, this being determined by the page size of the printer driver. Thus the virtual element, being non-transparent, will represent the non-transparent merged version of the original transparent element and the background after the positions of both the original transparent element and the underlying background have been determined by the printer driver. I don't like solution 2 for a couple of reasons: A) There is the possibility that a page may incorporate numerous transparent elements, requiring the creation of numerous virtual elements which would consume a lot of memory since the virtual elements much be generated for the printer's resolution. B) There is no way to guarantee that every possible style combination can be taken into account, such as multiple transparent elements nested within each other. An example: A table with transparent borders, possibly a transparent background or TD, and finally a transparent within the table. While using transparency is nice for element rendering within the browser, I conclude that the best solution for this bug at the time being is to strip the -moz-transparency style from the element before sending it to SPOOL32 and the printer driver. This will prevent the crash in SPOOL32.EXE. Thus the element will render with no transparency in Print Preview or on the printed page, allowing it to print although without transparency. Finally, I've never tested whether IE has similar problems crashing SPOOL32 when printing transparent elements.
Assignee: firefox → printing
Component: General → Print Preview
Product: Firefox → Core
QA Contact: general
Version: unspecified → 1.7 Branch
I've tested in IE and IE does not exhibit this problem when printing pages featuring elements with transparency.
Marcus, WFM with FF 1.5. Fails for you with v1.5?
(In reply to comment #9) > Marcus, WFM with FF 1.5. Fails for you with v1.5? > See my comment #7 for ideal solutions. This bug no longer generates a GPF since someone has already applied a quick fix to remove rendering of all objects with transparency during the print preview process. Note that transparent objects do seem to correctly print when sent to the printer, even though the transparent objects are not shown in print preview.
closing WFM per comment 10 and my testing. please raise the issues of comment 7 in other print bugs.
Status: UNCONFIRMED → RESOLVED
Closed: 19 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: