Closed Bug 213122 Opened 21 years ago Closed 21 years ago

Scrollbar partly locked up when dialog pops up from another window

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: MatsPalmgren_bugz, Assigned: bryner)

References

Details

(Keywords: fixed1.5, regression)

Attachments

(1 file)

patch
5.54 KB, patch
dbaron
: review+
dbaron
: superreview+
asa
: approval1.5+
Details | Diff | Splinter Review 
Scrollbar partly locked up when dialog pops up from another window

STEPS TO REPRODUCE:
1. Load a page that is long enough to cause a vertical scrollbar
2. Open another window and load an URL that will timeout or cause a dialog of
   some sort to popup.  An example: http://11.11.11.11:9999/
3. In the first window - scroll the scrollbar by dragging the scrollbar thumb
   with the mouse pressed down when the dialog from the other window popup
4. Release the mouse button and click away the dialog
5. Try to scroll the scrollbar again by dragging the scrollbar thumb

ACTUAL RESULTS:
It doesn't work, the scrollbar does not respond to dragging.
The other methods of scrolling still works though (page scroll, kbd scroll etc)
The problem is local only to the one window in question.

EXPECTED RESULTS:
Scrollbar functions as normal

PLATFORM & BUILDS TESTED:
Bug occurs on Mozilla 2003-07-14-22 trunk Linux
(this is a quite recent regression I think)
this regressed between linux trunk 2003070107 and 2003070205, perhaps bug 53579
Same here, under Win2k and Mozilla 1.5a (20030718)

Note that it has happened when I was on a tab. Only the current tab (when alert
about unreachable site appear) has scrollbar locked (when trying to move it
directly by mouse). Other tab's (same window) scrollbar working fine.

Workaround : click on a link of the scrollbar-locked page, then go back.
OS: Linux → All
I was able to reproduce, too (opening in tab).
*** Bug 213886 has been marked as a duplicate of this bug. ***
Severity: minor → normal
*** Bug 216071 has been marked as a duplicate of this bug. ***
*** Bug 216394 has been marked as a duplicate of this bug. ***
*** Bug 217152 has been marked as a duplicate of this bug. ***
-> me
Assignee: jag → bryner
Attached patch patch — — Splinter Review 
This code seems to be going to a great deal of work to only have the mediator
listen for events when a drag is not going on.	Checking whether a drag is
going on is very cheap, so I just changed it to do that.  The state can no
longer be out of sync, and it's no longer adding and removing the event
listener all the time.

I also cleaned up some unneeded nsIPresContext parameters to functions and got
rid of the cached mPresContext since we now have nsIFrame::GetPresContext().

(note, it's probably worth verifying that there are no other users of view
system mouse grabs that have internal state that must be kept consistent with
the grab)
Attachment #130642 - Flags: superreview?(dbaron)
Attachment #130642 - Flags: review?(dbaron)
*** Bug 217223 has been marked as a duplicate of this bug. ***
Flags: blocking1.5?
*** Bug 218047 has been marked as a duplicate of this bug. ***
*** Bug 212099 has been marked as a duplicate of this bug. ***
Does this patch fix bug 208225?
Comment on attachment 130642 [details] [diff] [review]
patch

Looks fine to me.  (Is there code that can be removed?)
Attachment #130642 - Flags: superreview?(dbaron)
Attachment #130642 - Flags: superreview+
Attachment #130642 - Flags: review?(dbaron)
Attachment #130642 - Flags: review+
this won't have any impact on selection
*** Bug 218824 has been marked as a duplicate of this bug. ***
I have windows xp and have seen this to. I geg it when some comes on to yahoo
messenger while I am scrolling locks up the scrollbar.  It me by any pop up
window will lock it.
Yes, even a popup from another software is doing the same thing.
(Realpopup -a well named- in my case)
Comment on attachment 130642 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to Mozilla 1.5
Attachment #130642 - Flags: approval1.5+
*** Bug 214621 has been marked as a duplicate of this bug. ***
*** Bug 219015 has been marked as a duplicate of this bug. ***
I didn't request 1.5 approval and I'm a bit hesitant about checking it in for
1.5 now.  At minimum this needs a couple of days to bake on the trunk.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 218890 has been marked as a duplicate of this bug. ***
spot any thing after trunk checkin?  if we are going to take this in 1.5 its
probably time to do it.
Flags: blocking1.5? → blocking1.5+
*** Bug 219723 has been marked as a duplicate of this bug. ***
*** Bug 219788 has been marked as a duplicate of this bug. ***
*** Bug 219994 has been marked as a duplicate of this bug. ***
*** Bug 219661 has been marked as a duplicate of this bug. ***
Given the number of duplicates I think this should be fixed for 1.5.

I haven't seen any reports of new problems on the trunk caused by this patch.
checked into 1.5 branch
Keywords: fixed1.5
*** Bug 220559 has been marked as a duplicate of this bug. ***
*** Bug 221357 has been marked as a duplicate of this bug. ***
Verified FIXED with build 2004-11-18-05 on Windows XP (bug was reported against
Linux originally, but was seen on Windows as well).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: