Going back to the previous web page sets vertical scrollbar [scroll bar] elevator in the wrong position [at top] using Classic theme

RESOLVED FIXED

Status

()

--
major
RESOLVED FIXED
16 years ago
15 years ago

People

(Reporter: jt.marsh, Assigned: bryner)

Tracking

({classic, qawanted, regression})

Trunk
PowerPC
Mac OS X
classic, qawanted, regression
Points:
---
Bug Flags:
blocking1.4b -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2], URL)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030409 Chimera/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030409 Chimera/0.7+

Go to www.lacie.com.
Scroll to the bottom of the page and click on any link.
Click the back button to return to the previous page.

Camino show the bottom of the page, but the scroll bar is at the top.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Expected Results:  
Scrollbar should be place at the bottom.

Comment 1

16 years ago
Confirmed using Camino/2003-04-08-05-trunk and FizzillaMach/2003-04-11-08-trunk.
Reassigning to Browser, XP Toolkit/Widgets, and adding qawanted as more triage
is needed.
Assignee: saari → jaggernaut
Status: UNCONFIRMED → NEW
Component: General → XP Toolkit/Widgets
Ever confirmed: true
Keywords: qawanted
Product: Camino → Browser
QA Contact: winnie → jrgm
Version: unspecified → Trunk

Comment 2

16 years ago
*** Bug 202287 has been marked as a duplicate of this bug. ***

Comment 3

16 years ago
Nominating as blocker for 1.4beta as it significantly impacts browser functionality
Flags: blocking1.4b?

Comment 4

16 years ago
Is this a general problem with all pages or specific to the lacie page? 

Comment 5

16 years ago
It's a general problem. I see it in Camino consistantly.

Comment 6

16 years ago
Nathan, can you give another example or two? It doesn't seem to happen using
<http://www.mozilla.org/> using FizzillaMach/2003-04-22-08-trunk and
Camino/2003-04-22-05.
Severity: normal → minor

Comment 7

16 years ago
Seems to have been fixed -- WFM in lastest nightly.

Comment 8

16 years ago
Really? FizzillaMach/2003-04-22-08-trunk exhibits the problem using
<http://www.lacie.com/>. Are you using a 4/24 build, Nathan?

I wonder what could have fixed it.

Comment 9

16 years ago
Still broken as of build 2003042408 on <http://www.lacie.com/>

Comment 10

16 years ago
All I know is that last week I started seeing "this" bug in Camino, except that
it was for any page. I never even tried the lacie page. After comment #6 I
downloaded the 4/24 Camino build and stopped seeing it for any page, including
the lacie page. Now, inexplicably, the same old build that had the problem
behavior before is doing just fine. I'm stumped. If I start seeing the bug again
with a fresh build I'll report back here.
wfm on my most recent camino build, from a couple days ago (unsure of exact date)

Comment 12

16 years ago
I can't repro on the latest Moz or Camino build at lacie or any of a handful of
other pages I tested. blocking1.4b-
Flags: blocking1.4b? → blocking1.4b-

Comment 13

16 years ago
It depends on something in the user profile. I was just now seeing it with
www.mozilla.org (of all places) and about 90% of the sites I would visit. Seemed
pretty random, but once a site showed the error it would do it consistently,
even between restarts and different Camino builds. I trashed my profile and now
everything is fine. But for how long...?

Comment 14

16 years ago
Created attachment 121756 [details]
Screen capture demonstrating the problem using FizzillaMach/2003-04-25-08-trunk

Still reproducible using FizzillaMach/2003-04-25-08-trunk. In this screenshot,
notice that the scroll elevator is wrongly at top of the bar.

Also notice that when the window is resized during this condition, detritus is
left behind.

(I'm using Pinstripe theme, based on Classic. Could this be Classic-only?)

Comment 15

16 years ago
I tried using the Modern theme in today's nightly MachO build and could not
reproduce it.  With Classic I can.  Camino also still has the bug.

Comment 16

16 years ago
Confirmed that it's only a bug using Classic theme.
Keywords: classic
Summary: Going back to the previous web page sets vertical scrollbar in the wrong position → Going back to the previous web page sets vertical scrollbar in the wrong position using Classic theme

Comment 17

16 years ago
Confirming this is still happening with Camino Build ID: 2003042605.

Comment 18

16 years ago
*** Bug 203465 has been marked as a duplicate of this bug. ***

Comment 19

16 years ago
*** Bug 203537 has been marked as a duplicate of this bug. ***

Comment 20

16 years ago
Revising summary; we're actually talking about the scroll elevator being in the
wrong position, not the bar.
Summary: Going back to the previous web page sets vertical scrollbar in the wrong position using Classic theme → Going back to the previous web page sets vertical scroll elevator in the wrong position using Classic theme

Comment 21

16 years ago
Note that this will also occur with scrolling form lists on a page.

1. Access the Bugzilla Query page
2. Scroll Product list to the bottom, showing Webtools
3. Click the "Component" link
4. Go back

Note that Product still shows the bottom of the list, but the elevator is at the
top of the list.

Comment 22

16 years ago
*** Bug 204695 has been marked as a duplicate of this bug. ***

Comment 23

16 years ago
*** Bug 204923 has been marked as a duplicate of this bug. ***

Comment 24

16 years ago
Added "scrollbar" to summary to make this bug easier to find.
Summary: Going back to the previous web page sets vertical scroll elevator in the wrong position using Classic theme → Going back to the previous web page sets vertical scroll elevator ( scrollbar ) in the wrong position using Classic theme

Updated

16 years ago
Summary: Going back to the previous web page sets vertical scroll elevator ( scrollbar ) in the wrong position using Classic theme → Going back to the previous web page sets vertical scrollbar elevator in the wrong position using Classic theme

Comment 25

16 years ago
*** Bug 205385 has been marked as a duplicate of this bug. ***

Comment 26

16 years ago
re: comment 16: this also occurs using the pinstripe theme (not a total surprise)

Comment 27

16 years ago
adding regression keyword

Going through Mozilla nightlies I have on hand I have a guestimate on this between:

2003040608 - good
2003041008 - bad
7 nightles since then all bad

I'd have to pull some moz builds to narrow it down anymore. As some parralel
data (and curiously different data then what has been reported by others here) I
can't repro this immediately the leclie example in Camino - 9 nightlies evenly
spread between 040905 & 050904 - and I flip between the 2 so often I'm can't say
for sure which of the 2 i've seen this in when.
Keywords: regression

Comment 28

16 years ago
WFM in FizzillaMach/2003-04-08-09-trunk, created at 5:23 AM. Chris, what was the
creation time of the 2003041008 build?

Comment 29

16 years ago
getinfo shows a create date on 041008 of apr 10, 2003, 8:25 AM [i'm on the east
coast if that matters]

Comment 31

16 years ago
CCing Robert. Robert, could any of your bugs mentioned in my comment 30 have
caused this bug?
I'm not sure what's going on exactly, but it's quite likely that bug 201300
interfered with the way native scrollbars work in Camino. Bug 201300 changed the
way scrollposition attribute changes are routed to nsGfxScrollFrame, to avoid
using a document listener.

Comment 33

16 years ago
*** Bug 205838 has been marked as a duplicate of this bug. ***

Comment 34

16 years ago
*** Bug 205963 has been marked as a duplicate of this bug. ***

Comment 35

16 years ago
nominating blocking 1.4... I know there isn't a proposed patch yet, but I don't
think this should make it into the stable branch if it can be helped.
Flags: blocking1.4?

Comment 36

16 years ago
If nobody has time to fix this, could bug 201300 simply be backed out for 1.4 if
indeed it's the cause?

Comment 37

16 years ago
*** Bug 206004 has been marked as a duplicate of this bug. ***

Comment 38

16 years ago
Another symptom that has not been mentioned here is when the page is in this
state, if you click the up or down scroll arrows or try to drag the scroll
elevator, the page will jump to the top. However, using the up/down arrows on
the keyboard has the opposite effect of causing the elevator to jump to reflect
the actual scroll position of the page. 

It's also intermittent. I see this problem frequently but had trouble getting it
to happen this morning until I went to the lacie page mentioned here. I had gone
to several long pages sequentially without triggering the bug, when I went to
the lacie page going back through the entire history of pages showed the symptom
where it had not shown before, including pages in different tabs. 
this happens in camino too. it's very annoying and a regression from the branch.
Severity: minor → major

Updated

16 years ago
Keywords: nsbeta1
(Assignee)

Comment 40

16 years ago
The NativeScrollbarFrame is not getting any AttributeChanged notification for
'curpos' when you go back to the previous page.  roc, any idea why that would be?
Like I said, look at the patch in bug 201300. We got rid of the document
listener in nsGfxScrollFrame and instead routed attribute changed notifications
to nsGfxScrollFrame by using the frame attribute change notification and having
that do a custom callback on nsGfxScrollFrame. I'm not sure how this could have
broken your native scrollbars but I bet that is it.

Comment 42

16 years ago
*** Bug 206623 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 43

16 years ago
Created attachment 124057 [details] [diff] [review]
fix

The problem is that the 'curpos' attribute is already set on the content node
at the time the NativeScrollbarFrame is created, so there is no attribute
change notification for it.  I've fixed it here by checking the value at the
end of Hookup() and propagating it to the native scrollbar if it's set to a
non-zero value.

We could do the same for maxpos/pageincrement/increment, but those seem to
always be set later and generate attribute change notifications.  Should we do
it anyway for consistency?  Or, instead, should we simply note that curpos is
present and wait to notify the scrollbar until after we find out maxpos? (which
would help the native scrollbar code do better bounds checking)
(Assignee)

Comment 44

16 years ago
Comment on attachment 124057 [details] [diff] [review]
fix

Looking for input... pink, what do you think?
Attachment #124057 - Flags: review?(pinkerton)

Comment 45

16 years ago
*** Bug 206903 has been marked as a duplicate of this bug. ***

Comment 46

16 years ago
updating summary to make this a tad easier to find... sorry for the spam
Summary: Going back to the previous web page sets vertical scrollbar elevator in the wrong position using Classic theme → Going back to the previous web page sets vertical scrollbar [scroll bar] elevator in the wrong position [at top] using Classic theme

Comment 47

16 years ago
adt: nsbeta1+/adt2

Brian has a fix so reassigning.
Assignee: jaggernaut → bryner
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
Comment on attachment 124057 [details] [diff] [review]
fix

seems fragile, but prolly the best we can get.
Attachment #124057 - Flags: review?(pinkerton) → review+
(Assignee)

Updated

16 years ago
Attachment #124057 - Flags: superreview?(sfraser)

Updated

16 years ago
Attachment #124057 - Flags: superreview?(sfraser) → superreview+

Comment 49

16 years ago
*** Bug 207396 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 50

16 years ago
fix checked in.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 51

16 years ago
Comment on attachment 124057 [details] [diff] [review]
fix

Is this something we want for the branch? What's the risk?
Attachment #124057 - Flags: approval1.4?

Comment 52

16 years ago
a=adt Please check into the Mozilla 1.4 branch after getting drivers approval
and add the keyword fixed1.4

Updated

16 years ago
Attachment #124057 - Flags: approval1.4? → approval1.4+
(Assignee)

Comment 53

16 years ago
fix checked in on MOZILLA_1_4_BRANCH.
Keywords: fixed1.4

Comment 54

16 years ago
Verified on the branch in build 2003060905

Marking verified1.4
Keywords: fixed1.4 → verified1.4

Comment 55

15 years ago
mozilla1.4 shipped. unsetting blocking1.4 request.
Flags: blocking1.4?
You need to log in before you can comment on or make changes to this bug.