171161 - Page back button of mouse produces strange behaviour

Status: VERIFIED FIXED

(Core :: Print Preview, defect, P1)

Description

[Wolfgang Hoessl]

Mozilla Version: 2002091014

Bug description:
Clicking on the back button (button #4) of my wheel mouse (MS IntelliMouse
Optical) in print preview, the page previous visited is getting loaded in this
module. After that the close button doesn't work any more, so you can't quit the
print preview.
Opening a new tab also doesn't work (print preview bar is shown instead of
navigation bar)

Reproduceability:

1. go to any  page
2. click at least on one link (back button must be enabled)
3. open print preview
4. use back button of your mouse
5. see result
6. try to open new tab
7. see result

Comment 1

[rods (gone)]

Currently, this both a UI and DocShell issue, the UI should never allow the
Back/Forward/Reload, or History to change the document while printing or PP is
occurring. The UI issue is Bug 171203.

Comment 2

[rods (gone)]

Attachment: patch v1

The patch:
1) Moves nsIDocumentViewerPrint.h from content/base/src/ to
content/base/public, until now it was used only by nsPrintEngine.cpp
2) Adds a macro for defining all the methods in nsIDocumentViewerPrint.h
3) Has the DocShell now check to see if the DV is Printing or PP when requests
are mde to change the "url" of the document (i.e. load a different page)
4) Show error dialog when user attempts to this
5) I also filed a bug on the UI, even though this is also a UI issue, the
DocShell should never let this happen.

Comment 3

[rpotts (gone)]

hey rod,

here a some comments on the patch:

- NS_ERROR_DOCUMENT_IS_PRINTMODE should really be an XPCOM error code. (In it's
current state it is actually considered an XPCOM success code)

- I'm a little afraid that ALL navigation is disabled when a DocViewer is in
Print or PrintPreview mode... What are the chances that we could get 'STUCK' in
print mode?

- I'm also not sure what would happen if a frame were printing and the
containing document changed!

-- rick

Comment 4

[Kevin McCluskey (gone)]

nsbeta1+

Comment 5

[rods (gone)]

Attachment: patch v2

This patch is a bit different, instead of having the DocShell figure out
whether it or one of its children are printing or PP, it gets told whether it
is, and it caches that value.

This was done so navigation is as fast as possible, meaning it doesn't have to
figure it out each time.

The patch:
1) Adds a method to the nsIContentViewerContainer to tell it whether we are
printing or in PP.
2) Fix up the DV and PrintEngine, the DV SetIsXXXX didn't need to set any
values in the PrintEngine, but now instead makes calls and sets the values in
DocShells
3) Cleaned up and add a macro to nsIDocumentViewerPrint

Comment 6

[dcone (gone)]

Comment on attachment 101267 [details] [diff] [review]
patch v2

r=dcone

Comment 7

[rpotts (gone)]

Comment on attachment 101267 [details] [diff] [review]
patch v2

sr=[e-mail]

Comment 8

[rods (gone)]

fixed

Comment 9

[Paul Wyskoczka]

Updated qa contact to [e-mail]

Comment 10

[sairuh (rarely reading bugmail)]

i don't have my mouse programmed for this --Wolfgang, is this still a problem
for you?

rs vrfy --pls reopen if this is a problem with a recent build.