Closed
Bug 511951
Opened 15 years ago
Closed 15 years ago
Cannot drag scroll bars on frames going from visibility:hidden to visibility:visible
Categories
(Core :: Layout, defect, P1)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a1
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta1-fixed |
People
(Reporter: sylvain.pasche, Assigned: roc)
References
Details
(Keywords: regression, testcase)
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
I noticed this issue on a meta-search web application which uses frames to show search engines results. I set a breakpoint in nsViewManager::GrabMouseEvents and noticed that IsEffectivelyVisible() is returning false when you try to drag the scroll bar in the attached testcase. Apparently, when setting the the frame visibility to "visible", some views are still in the nsViewVisibility_kHide state. Here's the view dump when loading the testcase with the frame having a visibility: hidden style and before setting it to visible: z=0 pos={0,0,35748,20952}) {0,0,35748,20952} z=0 vi s=1 clientData=097C63C0 < 05688820 {0,0,35748,20952} z=0 vis=1 clientData=097C68E8 < 0507FAD8 {0,0,35748,20952} z=0 vis=1 clientData=00000000 < 05274098 {0,0,35748,20952} z=0 vis=1 clientData=097C67D0 < 053539D0 {480,3054,18216,9216} z=0 vis=0 clientData=09764CA0 < 07DEEA30 {108,108,18000,9000} z=0 vis=0 clientData=00000000 < 07E64B80 {0,0,17982,9018} z=0 vis=1 clientData=097A1388 < 090E7E00 {0,0,17982,9018} z=0 vis=1 clientData=097A18B0 < 03DAF610 {0,0,16956,7992} z=0 vis=1 clientData=00000000 < 09101D88 {0,0,60480,60960} z=0 vis=1 clientData=097A1798 < > > 03ED2340 {16956,1026,1026,5940} z=0 vis=1 clientData=09810208 < > 056D3E68 {1026,7992,14904,1026} z=0 vis=1 clientData=0980F4D8 < > > > After setting the frame to visibility: hidden, we have: z=0 pos={0,0,35748,20952}) {0,0,35748,20952} z=0 vi s=1 clientData=097C63C0 < 05688820 {0,0,35748,20952} z=0 vis=1 clientData=097C68E8 < 0507FAD8 {0,0,35748,20952} z=0 vis=1 clientData=00000000 < 05274098 {0,0,35748,20952} z=0 vis=1 clientData=097C67D0 < 053539D0 {480,3054,18216,9216} z=0 vis=1 clientData=09764CA0 < 07DEEA30 {108,108,18000,9000} z=0 vis=0 clientData=00000000 < 07E64B80 {0,0,17982,9018} z=0 vis=1 clientData=097A1388 < 090E7E00 {0,0,17982,9018} z=0 vis=1 clientData=097A18B0 < 03DAF610 {0,0,16956,7992} z=0 vis=1 clientData=00000000 < 09101D88 {0,0,60480,60960} z=0 vis=1 clientData=097A1798 < > > 03ED2340 {16956,1026,1026,5940} z=0 vis=1 clientData=09810208 < > 056D3E68 {1026,7992,14904,1026} z=0 vis=1 clientData=0980F4D8 < > > > You can notice that one view has vis=0. This causes IsEffectivelyVisible() to return false. On the other hand, if you load the testcase with the frame having a visibility: visible style: z=0 pos={0,0,35748,20952}) {0,0,35748,20952} z=0 vi s=1 clientData=097C8940 < 0563E698 {0,0,35748,20952} z=0 vis=1 clientData=097C8E68 < 090B9CD8 {0,0,35748,20952} z=0 vis=1 clientData=00000000 < 03EEB618 {0,0,35748,20952} z=0 vis=1 clientData=097C8D50 < 080429D8 {480,3054,18216,9216} z=0 vis=1 clientData=09766148 < 05688820 {108,108,18000,9000} z=0 vis=0 clientData=00000000 < 057C0508 {0,0,17982,9018} z=0 vis=1 clientData=0978F440 < 05713A28 {0,0,17982,9018} z=0 vis=1 clientData=0978F968 < 03EF7C58 {0,0,16956,7992} z=0 vis=1 clientData=00000000 < 08F95CE8 {0,0,60480,60960} z=0 vis=1 clientData=0978F850 < > > 081DAFF8 {16956,1026,1026,5940} z=0 vis=1 clientData=09792A40 < > 056DF208 {1026,7992,14904,1026} z=0 vis=1 clientData=09791D10 < > > In this case, all views are visible and IsEffectivelyVisible() is returning true which makes the scroll bar works as expected.
Flags: blocking1.9.2?
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → roc
Assignee | ||
Comment 1•15 years ago
|
||
The problem is that we're making the inner view hidden if the frame's view is hidden, but after the deck widget removal patch, changing the frame's view to visible does not unhide the inner view. The solution is to just not hide the inner view. That's not needed since the hidden outer view makes all the descendants behave as effectively hidden.
Attachment #396399 -
Flags: review?(dbaron)
Assignee | ||
Updated•15 years ago
|
Whiteboard: [needs review]
Comment 2•15 years ago
|
||
Comment on attachment 396399 [details] [diff] [review] fix [Checkin: Comment 3 & 6] r=dbaron
Attachment #396399 -
Flags: review?(dbaron) → review+
Assignee | ||
Updated•15 years ago
|
Whiteboard: [needs review] → [needs landing]
Assignee | ||
Comment 3•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/e2af1f122512
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Assignee | ||
Updated•15 years ago
|
Flags: blocking1.9.2? → blocking1.9.2+
Comment 4•15 years ago
|
||
do we need additional approval to land this on 1.9.2? I just ran a quick test on a local build of 1.9.2 and this fixes the two dependent bugs.
Updated•15 years ago
|
Keywords: checkin-needed
Updated•15 years ago
|
Priority: -- → P1
Comment 6•15 years ago
|
||
Comment on attachment 396399 [details] [diff] [review] fix [Checkin: Comment 3 & 6] http://hg.mozilla.org/releases/mozilla-1.9.2/rev/356ca1cc0a60
Attachment #396399 -
Attachment description: fix → fix
[Checkin: Comment 3 & 6]
Updated•15 years ago
|
status1.9.2:
--- → beta1-fixed
Keywords: checkin-needed
Whiteboard: [needs 192 landing]
Target Milestone: --- → mozilla1.9.3a1
You need to log in
before you can comment on or make changes to this bug.
Description
•