crash in print preview with onClick in framesets [@ nsFrame::Destroy ]

VERIFIED FIXED

Status

()

Core
Print Preview
--
critical
VERIFIED FIXED
14 years ago
12 years ago

People

(Reporter: Antony Mawer, Unassigned)

Tracking

({crash, testcase})

Trunk
x86
All
crash, testcase
Points:
---
Bug Flags:
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

I was browsing a suppliers website earlier and went to print something, and when
accidentally clicking on the print preview display, Firefox crashed. The error
is 100% reproducable. I'll attach a reduced testcase in a moment.

Reproducible: Always
Steps to Reproduce:
1. Save the two attached files to disk somewhere
2. Open the frameset.html in the browser
3. Open File -> Print Preview
4. In the Print Preview display, click on the "Click here to crash!" link
Actual Results:  
Firefox crashed

Expected Results:  
Nothing

A few observations:

  * This seems to only occur when there are frames involved
  * If I put <!-- and // --> around the actual JavaScript body (within the
SCRIPT tag), then clicking no longer has any action

While an obscure bug, crashes are never good - I lost all the pages I had open
and the order I was placing. Unfortunately I can't provide the link to the
supplier as you require a dealer login to access the relevant page exhibiting
the bug.
(Reporter)

Comment 1

14 years ago
Created attachment 149569 [details]
Testcase part 1 - the HTML frameset
(Reporter)

Comment 2

14 years ago
Created attachment 149570 [details]
Testcase part 2 - the HTML frame
(Reporter)

Comment 3

14 years ago
I neglected to mention that Firefox appears to navigate to the new page
indicated as instructed by the onclick handler in the page. The title of the of
the window changes to that of the mozilla.org site, before the crash occurs
(possibly when it attempts to render the page and has nothing to render into?).

Comment 4

14 years ago
Created attachment 149572 [details]
On-line testcase
Attachment #149569 - Attachment is obsolete: true

Comment 5

14 years ago
Created attachment 149573 [details]
TB65580 stack (Linux, 20040518)

Updated

14 years ago
Keywords: crash, testcase
OS: Windows XP → All
Summary: crash in print preview with onClick in framesets → crash in print preview with onClick in framesets [@ nsFrame::Destroy ]

Comment 6

14 years ago
in a Linux debug build, this assertion shows up when clicking on the link in
print preview:
###!!! ASSERTION: Someone did not call nsIPresShell::destroy: 'Not Reached',
file nsPresShell.cpp, line 1691
Break: at file nsPresShell.cpp, line 1691

The stack is empty though.

No dupes found, marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: clean-report
The problem is probably that print preview sets a listener to cancel events on
the toplevel window only... and events don't bubble/capture across frames within
the content hierarchy.

Print preview needs to be setting the listener on the <browser> containing the
content or on each frame in the window.

Comment 8

14 years ago
bz, any idea as to which listener? The one I guessed at wasn't it :-/
Not offhand... I just recall print preview using some sort of listener setup to
block events...

Comment 10

14 years ago
Ah, actually print preview does not cancel events, you can verify this by
shift-clicking a link in print preview. What it does try to do is to cancel
scripts, but the method it uses doesn't work with frames.
Er.... That sucks.  It should really be cancelling all events with a capturing
chrome listener, if possible... :(

Comment 12

14 years ago
Yes, but you have to be careful not to cancel scrollbar events...
Right.  That can be done by examining the target, I would think....

Comment 14

14 years ago
What about scrollbars in <iframe>/<textarea>/<select>s?
You check not just the target but also the parent... It really shouldn't be hard
to distinguish them.  iframes/Textareas/selects shouldn't be scrollable in print
preview anyway (are they now?)

Comment 16

14 years ago
Ah, no, they're not. So one problem solved...

Comment 17

14 years ago
Created attachment 149644 [details] [diff] [review]
Lame hack

Hmm... this does stop the crash, and scrollbars still work...
Hmm.. So is nsPrintPreviewListener basically unused?

Comment 19

14 years ago
Created attachment 149656 [details] [diff] [review]
Better patch

Just uncommenting the code to add the listeners wasn't sufficient, presumably
because the listeners were bubbling and not capturing.

Let me know if there's a better way to set all these capturing listeners.
Attachment #149644 - Attachment is obsolete: true

Updated

14 years ago
Attachment #149656 - Flags: review?(jst)
Comment on attachment 149656 [details] [diff] [review]
Better patch

Hmm, this is a bit fragile given that as support for new input events is added
(i.e. DOM Level 3 Events' Text event etc) we'll potentially need to add them to
this list. But I can't really come up with a better solution to this right
now...

r=jst
Attachment #149656 - Flags: review?(jst) → review+

Comment 21

14 years ago
Comment on attachment 149656 [details] [diff] [review]
Better patch

Can't find a better sr, sorry.
Attachment #149656 - Flags: superreview?(jst)
Comment on attachment 149656 [details] [diff] [review]
Better patch

sr=jst
Attachment #149656 - Flags: superreview?(jst) → superreview+

Comment 23

14 years ago
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
So now scrollbars don't react to click events - bug 245751.
Verified FIXED using the
http://bugzilla.mozilla.org/attachment.cgi?id=149572&action=view testcase in
Print Preview on Windows XP (build 2004-08-16-13).
Status: RESOLVED → VERIFIED

Comment 26

13 years ago
Although I cannot reproduce the crash, this patch prevents users from right
clicking / middle clicking / etc. in the print previewed website, correct?

If so, this is something we might want for the Aviary Branch (along with the fix
for bug 245751). Nominating for Aviary 1.0.

Updated

13 years ago
Flags: blocking-aviary1.0?

Updated

13 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Crash Signature: [@ nsFrame::Destroy ]
You need to log in before you can comment on or make changes to this bug.