Closed Bug 162885 Opened 22 years ago Closed 22 years ago

scrolling shears on 10.2 in ppembed

Categories

(Core Graveyard :: Embedding: Mac, defect)

PowerPC
macOS
defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0.2

People

(Reporter: mikepinkerton, Assigned: mikepinkerton)

References

()

Details

(Keywords: topembed+)

Attachments

(2 files, 1 obsolete file)

- go to cnn.com in PPEmbed (8/15/02)
- scroll down, then up

notice the page "shears" and the left half doesn't scroll where the right half
does. seamonkey doesn't have this problem.

screenshot upcoming
Blocks: 150046
fwiw, i couldn't repro this with two chimera builds: the 2002.08.15.05 nightly,
and bryner's 1.0.1-sync build from last night. (tested w/spacebar, arrow keys
and pageUp/Down --no scrollwheel attached to the jaguar machine at hand.) not
sure how/when/if chimera would be affected by this, tho'...
i don't expect chimera to be affected. it's using different widget code entirely.
A piece of the puzzle. This does not occur on CNN.com when you disable 
JavaScript. 

Perhaps CNN serves different content for javascript disabled browsers?
http://bugscape.netscape.com/show_bug.cgi?id=19249
Keywords: topembed+
QA Contact: mdunn → mazielobo
i'll take it
Assignee: ccarlen → pinkerton
Target Milestone: --- → mozilla1.0.1
Sorry for the stupid question, but it's not specifically stated here... Does
this only occur on 10.2?
can someone in qa get a reduced test-case. it's obvious (from turning off JS)
that it is content dependent. that might help us narrow it down. petersen? can
you jump on this? it would be greatly appreciated!
Status: NEW → ASSIGNED
I could not reproduce the bug with 10.1.5.
i know why this is happening! oh happy day!

 in PPembed, we create a 32000 x 32000 widget as the toplevel. when we call
OffsetRgn() in nsWindow::CalcWindowRegion(), the call silently fails because for
some pages the region would get pushed over the 32767 limit. Then when we try to
restore the region's previous location, we end up ofsetting it and the shearing
occurs.

my best guess at a fix is two-fold:
- copy and restore the region rather than offset the region twice. this will
prevent us from ending up with a bad offset in the failure case
- don't have a toplevel widget of 32k x 32k.
Attached patch fixes for offset woes (obsolete) — Splinter Review
patch consists of two parts:

1) copy/restore region so even if OffsetRgn silently fails, we're still ok
2) don't create such a monumental main widget in embedding. ppembed pins the
max size of windows to the grayRgn already, so this is a reasonable size and
gives us a lot of room offset-wise to play before we hit the 32k limit.

note that (1) by itself fixes the shearing on cnn.com, but i'm not sure what
other side effects it might cause that aren't immediately visible. Very long
pages with a widget near the bottom (such as an iframe or a plugin) will still
run into this problem of bad offsets, but with (1) any issues that may arise
won't show themselves as shearing.
Comment on attachment 96462 [details] [diff] [review]
fixes for offset woes

+    nsRect r(0, 0, abs(grayRect.right - grayRect.left), abs(grayRect.bottom -
grayRect.top));

I don't think the abs is needed here. If so, this would be an empty rect.
without the abs(), r=ccarlen
Attachment #96462 - Flags: review+
+      StRegionFromPool originalWindowRgn;
+      if ( !originalWindowRgn )
+        return;
+      ::CopyRgn(parent->mWindowRegion, originalWindowRgn); 
+      ::OffsetRgn(parent->mWindowRegion, origin.x, origin.y);
+      ::SectRgn(mWindowRegion, parent->mWindowRegion, mWindowRegion);
+      ::CopyRgn(originalWindowRgn, parent->mWindowRegion);

Why not:

      StRegionFromPool parentShiftedWindowRgn;
      if ( parentShiftedWindowRgn )
        return;
      ::CopyRgn(parent->mWindowRegion, parentShiftedWindowRgn); 
      ::OffsetRgn(parentShiftedWindowRgn, origin.x, origin.y);
      ::SectRgn(mWindowRegion, parentShiftedWindowRgn, mWindowRegion);

so you just shift a copy of the parent? Then, there is no problem shifting it back.

Also agree with the abs() removal.
updated for smfr's comments. ignore the odd spacing, the surrounding code has
tabs.
Attachment #96462 - Attachment is obsolete: true
Comment on attachment 96483 [details] [diff] [review]
updated patch to simplify

sr=sfraser, tho maybe 
'shiftedParentWindowRgn' is a better name.
Attachment #96483 - Flags: superreview+
Comment on attachment 96483 [details] [diff] [review]
updated patch to simplify

r=sdagley
Attachment #96483 - Flags: review+
landed on trunk. holding open for 101 branch
It's too late for 1.0.1; retargeting for 1.0.2.  Once 1.0.1 is kicked out the
door, we'll take this asap for 1.0.2.  If an embedder needs this, they can
install it in their tree for now.
Target Milestone: mozilla1.0.1 → mozilla1.0.2
Comment on attachment 96483 [details] [diff] [review]
updated patch to simplify

a=chofmann for 1.0.2
Attachment #96483 - Flags: approval+
Comment on attachment 96483 [details] [diff] [review]
updated patch to simplify

a=chofmann for 1.0.2
landed on the 1.0 branch.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
mdunn: pls verify this as fixed on the 1.0 branch, then replace the "fixed1.0.2"
keyword, with "verified1.0.2". thanks!
Please verify the bug. Once verified, change the keyword fixed1.0.2 to
verified1.0.2 
Michael - need verification of this.  Pls reassign.
QA Contact: mazielobo → mdunn
Marking Verified Fixed.

Unable to reproduce. Tested against today's PPEmbed 20020924 1.0 branch
Status: RESOLVED → VERIFIED
Keywords: verified1.0.2
Brent... To be clear you tested against OSX 10.2 (Jaguar)?
Petersen do you have an OSX 10.2 install?
Yes, I have 10.2.1 installed. I will pull the same PPembed build as Brent and
try it.
Confirming the problem has been resolved in the 2002-09-24-05 PPembed branch build.
No longer blocks: 150046
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: