After smfr's scrolling speedups, scrolling with a scrollwheel in outliner would mess up. This didn't impact osx because we use the OS call to do all our scrolling. The problem was that simon put in a call to OffsetRgn, but this was already taken care of by Begin/EndUpdate so the resulting region that got invalidated was incorrect. Patch upcoming.
Created attachment 81703 [details] [diff] [review] fix invalidated region fixes bad invalidates on os9 needs r/sr
this needs to go on the trunk and the branch. cc'ing some more mac guys.
Status: NEW → ASSIGNED
Keywords: mozilla1.0, regression
Target Milestone: --- → mozilla1.0
Comment on attachment 81703 [details] [diff] [review] fix invalidated region r=sdagley
Attachment #81703 - Flags: review+
Does the case which Simon fixed, scrolling a dirty region (happens with "Find Next" in a doc which contains several close-together occurances) still work?
to answer conrad's question about the closely located find scrolling turds, it appears that smfr's last patch also regressed that fix, and this patch fixes those as well. Note that it doesn't fix every problem with find scrolling, but it doesn't appear to intoduce any new ones.
Created attachment 81765 [details] [diff] [review] better fix ok, so it appears that simon was in fact incorrect when he adjusted the visrgn into "local" coordinates of the widget. it caused not only the scrollwheel regression but turds appearing when scrolling small amounts and the find window would get blitted into the content area. this patch removes both instances of offsetting the region and fixes both regressions. when verifying this bug, please make sure that 127362 is still fixed (scrolling speed on long pages) and whatever bug the "scrolling small increments while doing a find leaves turds" is. need r/sr and if anyone in QA can run with this patch, it would be appreciated
Attachment #81703 - Attachment is obsolete: true
cc'ing brade as we discussed so she can run with this patch tomorrow.
Comment on attachment 81765 [details] [diff] [review] better fix sr=beard
Attachment #81765 - Flags: superreview+
Comment on attachment 81765 [details] [diff] [review] better fix r=sdagley
Attachment #81765 - Flags: review+
Comment on attachment 81765 [details] [diff] [review] better fix a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #81765 - Flags: approval+
oh mother, where art thou?
landed on the trunk. jrgm, can you work with se to verify that 127362 is still fixed even with this partial backout? and also give this a strong workout on os9? we need to make sure this is good and true before we put it on the branch.
I'll give this a workout on os9 and sairuh has graciously offered to recheck that bug 127362 has not regressed, in the next available trunk mac builds.
QA Contact: jrgm → sairuh
Good job on the fix, but we think this one can wait till RTM. adt1.0.0-/[adt3]
Keywords: adt1.0.0 → adt1.0.0-
Whiteboard: [ADT1] → [ADT3]
please, please, PLEASE reconsider--this bug is absolutely horrible! It's at least an adt2 in my experience but at times it's a show stopper (I will not be able to use the beta without this fix; I'll have to stick to trunk builds). I am seeing lots of repaint issues; I will attach some screenshots. The worst problem is in my inbox. When I delete a message it incorrectly updates all of the messages listed below it and sometimes I have deleted the wrong messages because it wasn't rendered properly. Oh, this has nothing to do with "scrollwheel" really; it's a general updating issue.
Keywords: adt1.0.0- → adt1.0.0
Summary: OS9 scrollwheel doesn't repaint correctly in outliner → OS9 scrolling doesn't repaint correctly in outliner or in other places
Whiteboard: [ADT3] → [ADT2]
i agree with brade. this is a STOP SHIP regression.
This is stopship for mozilla1.0 RC2 (that's what the 138000 dependency means). We must get this in before tomorrow.
upping back to adt1; this is such a showstopper; it is ***SOOOOooooo*** embarrassing to ship a beta with all of these update problems. initial jpeg coming...
Whiteboard: [ADT2] → [ADT1]
> upping back to adt1; this is such a showstopper; it is ***SOOOOooooo*** embarrassing I completely agree. Given the severity of the problem, the risk posed by the patch would have to be so huge (like deleting your whole mailbox) to justify thinking we don't need this fix in the beta. I'm confident that there's little to no risk here.
tested using 2002.05.02.03-trunk bits on Mac OS 10.1.4, with the classic (aqua) theme. the scrollwheel behaves fine --i checked out the following areas: webpages bookmarks mgr download mgr thread and folder panes of mailnews 3pane window history window xul file:/// listing gonna check this out on mac os 9.1 soon... btw, does it matter what theme i'm using? should i do both?
looks good on 9.1 (2002.05.02.03-trunk), both themes. both areas with outliners and web pages scroll fine with the scrollwheel (same tests in comment 21).
Whiteboard: [ADT1] → [ADT1][vrfy'd on trunk]
adt1.0.0+ (on ADT's behalf) approval for checkin to the 1.0 branch. Pls check this in to 1.0 branch today, then add the fixed1.0.0 keyword.
Keywords: adt1.0.0 → adt1.0.0+
Whiteboard: [ADT1][vrfy'd on trunk] → [ADT1][vrfy'd on trunk] [ETA 05/02]
landed on branch
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Keywords: adt1.0.0+ → fixed1.0.0
Resolution: --- → FIXED
looks fine (no regressions) using 2002.05.03.09-1.0.0 bits on Mac 10.1.4. still waiting on 9.x branch bits to become available...
vrfy'd fixed using 2002.05.06.05-1.0.0 (branch) comm bits on mac 9.1.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.