Closed
Bug 209706
Opened 23 years ago
Closed 19 years ago
Scrollbars can draw when their container widgets are hidden
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: sfraser_bugs, Unassigned)
References
Details
Attachments
(1 file)
|
3.22 KB,
patch
|
ccarlen
:
review+
bryner
:
superreview+
|
Details | Diff | Splinter Review |
In an embedding app that uses carbon events, it's possible for scrollbars to
draw when they should be hidden. The problem is that control drawing happens via
carbon events and the control hierarhcy, bypassing Gecko, and we never hide the
native controls when we hide their parent widgets.
| Reporter | ||
Comment 1•23 years ago
|
||
P
| Reporter | ||
Comment 2•23 years ago
|
||
Comment on attachment 125864 [details] [diff] [review]
Patch to call ContainerHierarchyIsVisible() from the draw event handler
Note that diff was -w, and I'm detabbing the MacControlDrawHandler() function.
nsWindow.h has a mess of spaces/tabs in it.
Attachment #125864 -
Flags: superreview?(bryner)
Attachment #125864 -
Flags: review?(ccarlen)
Comment 3•23 years ago
|
||
Comment on attachment 125864 [details] [diff] [review]
Patch to call ContainerHierarchyIsVisible() from the draw event handler
Is it worth it to ensure that the native control is hidden when its widget is
hidden so that the event handler doesn't fire when it shouldn't in the first
place?
But, since the container visibility check looks fast, and this is a good safety
net, r=ccarlen
Attachment #125864 -
Flags: review?(ccarlen) → review+
| Reporter | ||
Comment 4•23 years ago
|
||
To do that we'd have to trawl through child widgets ever time an ancestor widget
gets hidden, looking for native controls to hide. Since hiding and showing is
less common that drawing, that might be more efficient, but is more work.
Updated•23 years ago
|
Attachment #125864 -
Flags: superreview?(bryner) → superreview+
Dup of bug 187435?
Comment 6•21 years ago
|
||
Is this patch still valid? As said in comment 5, this is the same issue as bug
187435
Comment 7•21 years ago
|
||
-> Widget: Mac (based on patch)
Requesting blocking1.8b3, since this has a simple, reviewed, patch.
Comment 8•21 years ago
|
||
It turnes out that the patch is for Mozilla 1.2 branch code which never got
applied to the trunk (see bug 205873).
Removing blocking request and apologizing for the spam.
Flags: blocking1.8b3?
Comment 10•20 years ago
|
||
Would this (possibly outdated?) patch fix bug 187435 ?
| Reporter | ||
Comment 11•20 years ago
|
||
I think Mark has made changes that make this patch obsolete. Reassigning to him to do what he wants with it.
Assignee: sfraser_bugs → mark
Status: ASSIGNED → NEW
Comment 12•19 years ago
|
||
I bet this was fixed with our cocoa scrollbar rewrite...
Assignee: mark → joshmoz
Component: Widget: Mac → Widget: Cocoa
QA Contact: jrgmorrison → cocoa
Comment 13•19 years ago
|
||
This is fixed with cocoa widgets and HITheme scrollbar drawing.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Status: NEW → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•