Closed Bug 205873 Opened 18 years ago Closed 5 years ago

In embedding apps using Carbon Events, scrollbars can draw in the wrong place

Categories

(Core :: XUL, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: sfraser_bugs, Unassigned)

Details

Attachments

(1 file)

We use native scrollbar controls in Mac widget code. In Mozilla, we have
complete control over when these draw, because all drawing and event handling
goes through Gecko (in theory). We bracket all calls that might cause drawing
with StartDraw() and EndDraw() in the mac widget code.

If an embedder starts using Carbon Events, and installs the standard window
handler on their window, this picture changes. The SWH activates controls on
window activation, for example, and this bypasses Gecko. Gecko's controls
therefore draw in the wrong place.
Patch coming.
Assignee: jaggernaut → sfraser
This patch installs a Carbon Event handler on the kEventControlDraw event, and,
if necessary, calls StartDraw()/EndDraw() around CallNextEventHandler().

With this patch, we may be able to remove many of the StartDraw/EndDraw calls
in this code.
any chance to get the fix in Mozilla ?
I would like to see the fix in.
so we may be able to have Mozilla Browser widget in Eclipse SWT as another 
Browser widget option.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=78048
This will become irrelavent with Cocoa widgets.
Assignee: sfraser_bugs → joshmoz
Is this even still a problem?  I included a modified version of the patch here in the final fix for bug 311399.
In trunk, it moved Cocoa Widget.
FIXED ?
Assignee: joshmoz → nobody
RIP Carbon
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.