383670 - Many XUL widgets don't catch mouse events when they are placed above a titlebar element

Status: NEW

(Toolkit :: UI Widgets, defect)

Description

[Ian McKellar]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20061201 Firefox/2.0.0.4 (Ubuntu-feisty)
Build Identifier: 

The <xul:titlebar> element allows a region of a window to be used to drag the window around - just like a title bar.

To make a window draggable you can create a stack with a titlebar on the bottom like this:
<stack>
  <titlebar />
  <vbox mousethrough="always">
    ...xul goes here...
  </vbox>
</stack>

This works pretty well. For example you can click on buttons, but when you drag a label it moves the window. On the other hand many xul widgets do not work correctly. For example clicking on a text box doesn't focus it - the event passed through to the titlebar and a window drag begins.

We're moving to this dragging mechanism in Songbird and I'm preparing a patch to toolkit to add mousethrough="never" to XUL widgets that should receive mouse events.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Neil Deakin]

I don't see any issues here. Do you have a testcase?

There shouldn't be any mousethrough attributes added.

Comment 2

[Ian McKellar]

I've got a very simple test-case at: http://scratch.ianloic.com/bug383670.xul

it works with "firefox -chrome http://scratch.ianloic.com/bug383670.xul"

It has a stack with a titlebar at the bottom (coloured so we can see that it takes up the whole region). On top there is a label that we can drag to move the window, a button which works as expected, a textbox that cannot be focussed with the mouse and when dragged moves the window and one with mousethrough="always" that works as expected.

I've only tested this on Linux. I suspect that the difference between the button and the textarea are native vs toolkit widgets. I'll have a better idea of the state of the other platforms next week.

Comment 3

[Ian McKellar]

Attachment: That test-case

Here's that test-case

Comment 4

[Neil Deakin]

So what is the bug here?

Buttons have an implied mousethrough="never" so they pressing them will work even in the presence of mousethrough="always", although I don't actually know why buttons are special cased like this.

Any other element that should accept mouse events should have mousethrough="never" on it, as the second textbox does.