122048 - [FIX]Print preview on screen with applets hangs on Reload/Back

Status: VERIFIED FIXED

(Core :: Print Preview, defect)

Description

[Dom Incollingo]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+)
Gecko/20020125
BuildID:    2002012503

When print preview is performed on (certain) pages with applets, Mozilla hangs
when the Reload or Back button is chosen to return to return to normal (not
Print Preview) mode.

Reproducible: Always
Steps to Reproduce:
1.Navigate to http://java.sun.com/ or http://www.visitor.calgary.ab.ca/.  Both
sites use applets.
2.Choose Print Preview.
3.Following Print Preview, choose the Reload button to display the original
screen image.

Actual Results:  The browser hangs when the Reload button is pressed.  The
screen image does not return to its original (not Print Preview) display.  In
addition, I can not navigate to any other pages, either by entering the URL or
selecting a bookmark.  

Windows Task Manager indicates that Mozilla is 'Running' (rather than 'Not
Responding'), but I waited for three minutes and Mozilla continued to hang for
this entire time.  (I cancelled Mozilla from Task Manager after three minutes.)

Note that if you naviate to one of these two URLs, choose Print Preview, and
then choose the Back button (instead of Reload), the same result occurs: the
browser hangs.

Expected Results:  If the Reload button is chosen, the screen image should
refresh to its original (prior to Print Preview) display.  If the Back button is
chosen, the browser should display the prior page.  The browser should not hang.

Running Mozilla on Win 2K with 512 MB of RAM.

Comment 1

[Dom Incollingo]

Attachment: Mozilla when Reload was selected following Print Preview on http://java.sun.com/

Note that Task Manager indicates that Mozilla is 'Running', but Mozilla hung
and remaind in Print Preview mode for 3 minutes.

Comment 2

[Dom Incollingo]

Attachment: Mozilla when Reload selected following Print Preview on http://www.visitor.calgary.ab.ca/

Same comment as for first attachment.

Comment 3

[Andrew Hagen]

Confirming on Windows 98, Build ID: 2002020103, Java 2 Runtime Environment,
Standard Edition (build 1.3.1_01). Language: English/US.

After the hang, I could exit Mozilla. The browser window closed. But, the
Ctrl-Alt-Del task list still listed Mozilla. I had to cancel the task manually.

Adding keyword "hang."

Comment 4

[Andrew Hagen]

Really confirming.

Comment 5

[Kevin McCluskey (gone)]

It hangs using 2002022003 build when closing the print preview window after
print previewing http://java.sun.com/.

Marking nsbeta1+. 

Comment 6

[Andrew Hagen]

Changing component from printing to print preview.

Comment 7

[Matthias Versen [:Matti]]

*** Bug 127606 has been marked as a duplicate of this bug. ***

Comment 8

[rods (gone)]

Attachment: patch

This patch enables use to cache the current presentation and then restore it
when exiting PP.

It also fixes nsObjectFrame::Paint to paint the plugin in the right place.

Comment 9

[rods (gone)]

Attachment: full patch

includes changes from previous patch plsu this adds the pref
"print.always_cache_old_pres" to all.js

Comment 10

[Peter Lubczynski]

*** Bug 113317 has been marked as a duplicate of this bug. ***

Comment 11

[rods (gone)]

Attachment: full patch

Full patch and it now includes code for UNIX plugins to paint an empty rect
when in PP.

Comment 12

[rods (gone)]

Attachment: patch

Full patch, but changed so that plugins don't paint at all in Print Preview.
This is needs an entirely different fix that is more involved than we have time
for.

Comment 13

[Syd Logan]

adt1 per adt triage

Comment 14

[rods (gone)]

Attachment: patch

Generically enables the browser to cache the curent presentation (frames,
views, et.al.) for Print Preview and then enables them to be restored.

It uses a pref and/or checks all the documents to see if any have an "embed" or
a "plugin". Temporarily it checks for framesets and turns on caching also.

I also factored some code in the Init routine so it could be callled for either
creating the new presention or initializing an existing one.

Also, added some safety check code in PrintPage.

Then for the object frame, for PP it doesn't do a paint - this is a temporary
fix.

Comment 15

[Peter Lubczynski]

Comment on attachment 75585 [details] [diff] [review]
patch

r=peterl, no more hang

Comment 16

[Marc Attinasi]

Comment on attachment 75585 [details] [diff] [review]
patch

I like the general idea of the patch, and the code looks good, but I really
dislike that the caching is tied tightly to Print Preview. This should be a
general facility - maybe Print Preview is the only place it is used for a
while, but I cannot think of any good reason to tie it to Print Preview and as
a result prevent other uses of it (an example that comes to mind is caching the
presentation of the previous page in case the user hits back - or storing the
presentation for the last 'n' pages, tied to the history - or something).

Can we generalize it a tad and not make it a PrintPreview only feature? Or am I
over generalizing here?

Comment 17

[rods (gone)]

The general case could be a new feature, but at the moment PP is the only one
where there is a requirement. Plus, very soon we want to move Plugins over to
content anway...

Comment 18

[Marc Attinasi]

Comment on attachment 75585 [details] [diff] [review]
patch

I am a little concerned that DocumentViewer is getting too entangled in Print
Preview-specific stuff. However, I think the gravity of the bug outweighs my
immediate concern for code purity, sr=attinasi

One note: the CachedPresentation data member in the PrintObject could easily be
an object instance instead of a pointer, as the COMPtr's in it can be set and
null'd easily - you would just need a 'clear' method on it to use instead of
deleting it. This would avoid having to allocate it and free it.

Comment 19

[rods (gone)]

Since the CachedPresentationObj gets handed off from PrintData object to the
next PrintData object it is much handier to have it be a pointer. 

Ready for approval.

Comment 20

[Andrew Hagen]

*** Bug 133029 has been marked as a duplicate of this bug. ***

Comment 21

[rods (gone)]

*** Bug 127969 has been marked as a duplicate of this bug. ***

Comment 22

[rods (gone)]

*** Bug 108509 has been marked as a duplicate of this bug. ***

Comment 23

[rods (gone)]

*** Bug 131616 has been marked as a duplicate of this bug. ***

Comment 24

[Asa Dotzler [:asa]]

Comment on attachment 75585 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 25

[rods (gone)]

fixed

Comment 26

[Adam D. Moss]

I'd be interested in seeing a bug about making this
facility a bit more generic and using it elsewhere.
Do you fancy filing one, Marc?

Comment 27

[sujay]

verified in 3/27 build.

REOPEN if this is not fixed for anyone...

Comment 28

[sujay]

this problem is gone now...

however, now I see another problem:

in PP mode, should applets render? I"m getting different results on
different platforms. On windows, I don't see the applet in PP mode.
On Mac, I do see it, but it is shifted over a bit...filing a bug

Also Peter wanted me to see how plugins behave in PP mode...might
file a bug on that also if I see a problem.

Comment 29

[sujay]

http://bugzilla.mozilla.org/show_bug.cgi?id=133992

filed this bug on applets rendering inconsistently in PP mode
if anyone is interested in cc:'ing themselves on that bug...

Comment 30

[Peter Lubczynski]

Plugins should not render at all in PP because we can't do it correctly at this
time.

The Mac has a bug in that the orriginal applet from the page is never hidden
(hiding parent widget doesn't hide plugin's) and therefore shows up in PP, in
the wrong location. Let's use bug 133992 to fix that isssue and open a new bug
to implement PP for plugins for post mozilla 1.0.