270456 - Print preview generates a general protection fault.

Status: RESOLVED WORKSFORME

Description

[Michael Marcus]

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

Comment 1

[timeless]

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.

Comment 2

[Michael Marcus]

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.

Comment 3

[Michael Marcus]

Created attachment 166564 [details]
Zip of Dependency Walker run, calls, and crash in SPOOL32.EXE.

Comment 4

[Michael Marcus]

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.

Comment 5

[timeless]

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

Comment 6

[Bernd]

the url is not reachable

Comment 7

[Michael Marcus]

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.

Comment 8

[Michael Marcus]

I've tested in IE and IE does not exhibit this problem when printing pages
featuring elements with transparency.

Comment 9

[Wayne Mery (:wsmwk)]

Marcus, WFM with FF 1.5.  Fails for you with v1.5?

Comment 10

[Michael Marcus]

(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.

Comment 11

[Wayne Mery (:wsmwk)]

closing WFM per comment 10 and my testing.
please raise the issues of comment 7 in other print bugs.