Closed Bug 111432 Opened 23 years ago Closed 19 years ago

[FIRST] Mouse wheel scrolling doesn't work in print preview on page margin or on frame page

Categories

(Core :: Print Preview, defect, P1)

Product:
Core
Component:
Print Preview
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8.1

People

(Reporter: mik, Assigned: masayuki)

References

Details

(Keywords: fixed1.8.1, relnote, testcase)

Attachments

(3 files, 3 obsolete files)

Test case showing boundary
945 bytes, text/html
Details
Test case for print preview bug
2.74 KB, text/html
Details
Patch rv3.0
5.77 KB, patch
roc
: review+
roc
: superreview+
roc
: approval-branch-1.8.1+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+)
Gecko/20011120
BuildID:    2001112003

In print preview mode mouse wheel is beaing almost ignored,
only scrolling a few lines after some scrolling with scroll-bar.

Reproducible: Always
Steps to Reproduce:
1. Open any page
2. Select "Print Preview" option in "File" menu
3. Move mouse wheel up and down

Actual Results:  Page scrolls a few lines sometime and stops.  
Scrolling with scroll bar sometimes helps to scroll with a wheel for
anothwr few lines.

Expected Results:  Page scroll smoothly up and down as in ordinary case.
Add to this that moving down with the space bar or cursor keys doesn't work
either in print preview mode (platform: Solaris/sparc, build: 0.9.6).
confirming on linux 2001112121.
It seems to work if the pointer is on a non-blank space (text, form elements,
images)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Related: bug 110145.
The keyboard scrolling issue is bug 109566
Assignee: dcone → rods
Blocks: 103890
Summary: Mouse wheel does'nt works in print preview → Mouse wheel scrolling doesn't work in print preview
I think it is pretty much the same issue as bug 109566, but it is not time to 
dup them yet.

I need to first let the document have focus, then make the scrollbats can get 
the events.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
*** Bug 112521 has been marked as a duplicate of this bug. ***
The event processing issues have been fixed, reopen if not.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
verified.
Status: RESOLVED → VERIFIED
Reopening.
It is still not possible to scroll with the mousewheel when the pointer is on
white space in the page.

It scrolls fine when the pointer is on text.
It scrolls fine when the pointer is outside the previewed page.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 126972 has been marked as a duplicate of this bug. ***
I'm seeing this with a 10 hours old CVS build on linux.
Status: REOPENED → ASSIGNED
Summary: Mouse wheel scrolling doesn't work in print preview → [FIRST]Mouse wheel scrolling doesn't work in print preview
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future
probably just busted again resently with some new print-preview checkins.  Just
taking a guess that the patch that fixed this didn't get into the landing code
for the print-preview work, ie didn't get in before the code was pulled &
modified again for the latest code change landing, otherwise, dunno.
Changing component from printing to print preview.
Component: Printing → Print Preview
*** Bug 133005 has been marked as a duplicate of this bug. ***
*** Bug 150174 has been marked as a duplicate of this bug. ***
Still seeing this problem with

  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826

Scrolling only works when the mouse pointer is outside the previewed page or
when positioned on top of non-blank parts of the page (text, form elements, ...)


*** Bug 186796 has been marked as a duplicate of this bug. ***
*** Bug 187981 has been marked as a duplicate of this bug. ***
*** Bug 193981 has been marked as a duplicate of this bug. ***
Keywords: relnote
QA Contact: sujay → sairuh
Confirming bug on:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030811

I don't know if this helps, but I made a test case showing the boundary between
where the wheel mouse responds and where it doesn't.  The test case has a
margin around the <html> element, and also a thick green border around the
<html> element.  

The mouse wheel responds anywhere on or inside the <html> border.  Outside, in
the <html> margin and the page margin, it does not respond.  However, in the
dark grey background outside of the "pieces of paper", it does respond again. 
Note that the <html> margin is easier to see if you select File | Page Setup,
and check "Print Background" so that the colored page background appears in the
print preview.
->bryner

Brian, there's a good testcase in the comment above this one. Can you take a
look at it and see if there's any quick fix for this? Thanks.
Assignee: rods → bryner
Status: ASSIGNED → NEW
*** Bug 232629 has been marked as a duplicate of this bug. ***
Keywords: testcase
This bug still exists on:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040428
Firefox/0.8.0+

Can it at least be marked as confirmed?
Yeah, this is a very annoying bug. It still exists in version 1.0PR
*** Bug 245278 has been marked as a duplicate of this bug. ***
*** Bug 225974 has been marked as a duplicate of this bug. ***
*** Bug 307514 has been marked as a duplicate of this bug. ***
Still here on publicly available FF 1.5 Beta 1
*** Bug 261319 has been marked as a duplicate of this bug. ***
It seems that in the DoScrollText() function of nsEventStateManager.cpp (see
<http://lxr.mozilla.org/mozilla/ident?i=DoScrollText>) both the
aTargetFrame->GetContent() and the GetFocusedContent() call fail, causing an
early return before a scroll event is created.

I don't know whether another way to retrieve the content object is needed or
another target frame has to be passed to the DoScrollText() function, though.
*** Bug 310012 has been marked as a duplicate of this bug. ***
*** Bug 275488 has been marked as a duplicate of this bug. ***
*** Bug 311612 has been marked as a duplicate of this bug. ***
*** Bug 317011 has been marked as a duplicate of this bug. ***
Using the mouse wheel to scroll in print preview works until the cursor approaches a the page separator.
taking.
Assignee: bryner → masayuki
Summary: [FIRST]Mouse wheel scrolling doesn't work in print preview → [FIRST] Mouse wheel scrolling doesn't work in print preview on page margin
Target Milestone: Future → mozilla1.9alpha
Status: NEW → ASSIGNED
Attached patch Patch rv1.0 (obsolete) — — Splinter Review 
We should always scroll root scroll view in print preview mode.
Attachment #205849 - Flags: superreview?(roc)
Attachment #205849 - Flags: review?(roc)
Comment on attachment 205849 [details] [diff] [review]
Patch rv1.0

This is not good.
If on print preview mode, the mouse event is not fired.
Attachment #205849 - Flags: superreview?(roc)
Attachment #205849 - Flags: review?(roc)
Attachment #205849 - Flags: review-
Attached patch Patch rv2.0 (obsolete) — — Splinter Review 
This is better than previous patch.
But this patch cannot fix the case of on the frame page...
Because:
> vm->GetRootScrollableView(&scrollView);
This returns null.
Attachment #205849 - Attachment is obsolete: true
Attachment #205991 - Flags: superreview?(roc)
Attachment #205991 - Flags: review?(roc)
Comment on attachment 205991 [details] [diff] [review]
Patch rv2.0

+#define SHOULD_SCROLL_ROOT_VIEW(pc) \
+          (pc->Type() == nsPresContext::eContext_PrintPreview)

Make it a static function. That's always better than a macro, when possible.

>>> But this patch cannot fix the case of on the frame page...
Because:
> vm->GetRootScrollableView(&scrollView);
This returns null. <<<

Can you explain this more?
Attached patch Patch rv3.0 — — Splinter Review 
This patch fix all wheel scroll problem on Print Preview.
This fixes the issue of the frame page.
E.g., please test on following page:
http://www.mozilla-japan.org/projects/toolkit/review.html

But I don't know this logic is correct.
> +  nsIPresShell *pPresShell = nsnull;
> +  for (PRUint32 i = 0; i < parentDoc->GetNumberOfShells(); i++) {
> +    nsIPresShell *tmpPresShell = parentDoc->GetShellAt(i);
> +    NS_ENSURE_TRUE(tmpPresShell, NS_ERROR_FAILURE);
> +    NS_ENSURE_TRUE(tmpPresShell->GetPresContext(), NS_ERROR_FAILURE);
> +    if (tmpPresShell->GetPresContext()->Type() == aPresContext->Type()) {
> +      pPresShell = tmpPresShell;
> +      break;
> +    }
> +  }

If a document has two or more print preview presContext, this code is wrong...
Attachment #205991 - Attachment is obsolete: true
Attachment #205992 - Attachment is obsolete: true
Attachment #206087 - Flags: superreview?(roc)
Attachment #206087 - Flags: review?(roc)
Attachment #205991 - Flags: superreview?(roc)
Attachment #205991 - Flags: review?(roc)
Summary: [FIRST] Mouse wheel scrolling doesn't work in print preview on page margin → [FIRST] Mouse wheel scrolling doesn't work in print preview on page margin or on frame page
Roc:

Could you review it?
Comment on attachment 206087 [details] [diff] [review]
Patch rv3.0

the GetPresShellAt code isn't great but I can't think of anything better. We'll unify the view manager hierarchies and this problem will be easier to solve then.
Attachment #206087 - Flags: superreview?(roc)
Attachment #206087 - Flags: superreview+
Attachment #206087 - Flags: review?(roc)
Attachment #206087 - Flags: review+
checked-in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 19 years ago
Resolution: --- → FIXED
Comment on attachment 206087 [details] [diff] [review]
Patch rv3.0

We don't have any regression reports.
This bug has many dup bugs. Let't go to 1.8.1.
Attachment #206087 - Flags: approval1.8.1?
Flags: blocking1.8.1?
Confirmed - this issue both in Firefox 1.0.7 and 1.5.

If you scroll with cursor on the grey right-side edge next to the scrollbar or on white area of a page, it works fine from page 1-X.  If you scroll with cursor over a white area of a page though, it works until it hits the page-page margin area. 


Confirmed - this issue both in Firefox 1.0.7 and 1.5.

If you scroll with cursor on the grey right-side edge next to the scrollbar or
on white area of a page, it works fine from page 1-X.  If you scroll with
cursor over a white area of a page though, it works until it hits the page-page
margin area.

i.e. THIS IS NOT FIXED!
(In reply to comment #49)
> Confirmed - this issue both in Firefox 1.0.7 and 1.5.

> i.e. THIS IS NOT FIXED!

Bugzilla's "FIXED" resolution means "fixed on the trunk", not "fixed in all released versions". This bug *is* fixed on the trunk, i.e. the latest Firefox codebase. It was not fixed for 1.0.7 or 1.5, as you've discovered. The patch is awaiting approval for the 1.8 branch, which means it may be fixed in Firefox 2; otherwise, it will be fixed in Firefox 3.
*** Bug 324802 has been marked as a duplicate of this bug. ***
Attachment #206087 - Flags: branch-1.8.1?(roc)
Attachment #206087 - Flags: approval1.8.1?
Roc:

Please check this bug can go to 1.8.1 or not so.
This bug might not have any regressions and this is not changing any APIs.
Comment on attachment 206087 [details] [diff] [review]
Patch rv3.0

The bug is not serious and the patch is not trivial.
Attachment #206087 - Flags: branch-1.8.1?(roc) → branch-1.8.1-
Comment on attachment 206087 [details] [diff] [review]
Patch rv3.0

I changed my mind. This is a polish fix and so it might as well go in.
Attachment #206087 - Flags: branch-1.8.1- → branch-1.8.1+
Thanks,
Flags: blocking1.8.1?
Keywords: fixed1.8.1
Target Milestone: mozilla1.9alpha → mozilla1.8.1
I have this bug with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060415 Firefox/3.0a1.
*** Bug 338266 has been marked as a duplicate of this bug. ***
This bug has regressed on the trunk, see bug 338266.
*** Bug 353834 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: