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

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[Simon Fraser [no longer active]]

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.

Comment 1

[Simon Fraser [no longer active]]

Patch coming.

Comment 2

[Simon Fraser [no longer active]]

Attachment: Patch (on the Moz 1.2 branch) which helps

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.

Comment 3

[Hiroyuki Okamoto]

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

Comment 4

[Simon Fraser [no longer active]]

This will become irrelavent with Cocoa widgets.

Comment 5

[Mark Mentovai]

Is this even still a problem?  I included a modified version of the patch here in the final fix for bug 311399.

Comment 6

[Hiro]

In trunk, it moved Cocoa Widget.
FIXED ?

Comment 7

[Frankie]

RIP Carbon