517185 - motion-notify handler returns true and stopping any other handler for motion-notify being invoked

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Simon Schampijer]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090909 Fedora/3.5.3-1.fc11 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090909 Fedora/3.5.3-1.fc11 Firefox/3.5.3

The motion-notify handler returns true and stopping any other handler for motion-notify being invoked. In the browser of the Sugar platform using xulrunner, one can not listen on this event.

Code path in mozilla: http://mxr.mozilla.org/firefox/source/widget/src/gtk2/nsWindow.cpp#4653

More infos: http://bugs.sugarlabs.org/ticket/1309#comment:4

Reproducible: Always

Comment 1

[Tomeu Vizoso]

Simon, can you set this bug's component to something like "Widget - GTK (supported X widgetry and gfx)"? That will put it in the radar of who can do something about it.

Comment 2

[Tomeu Vizoso]

Attachment: proposed fix

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Tomeu, I got someone to give you editbugs and canconfirm powers.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What about the button press and release events, which also return TRUE?

I'm not sure why we should tell GTK we didn't handle these events, since we actually do handle them.

Comment 5

[Karl Tomlinson (:karlt)]

key_press_event_cb returns true only on nsEventStatus_eConsumeNoDefault.
Maybe other handlers could do the same.

Or perhaps Owen is right that notification events should always be propagated.
Though if a mouse button is down it might make sense not to propagate.

The value returned is really more an indication of whether to propagate than
whether the event was processed.

"Returns :
	TRUE to stop other handlers from being invoked for the event. FALSE to
	propagate the event further."

I assume Sugar is trying to listen on an ancestor widget (rather than
Mozilla's GtkWidget), so listening to the "event" signal is not an option.

I can't think of any problems from always propagating motion-notify events
(because we only have one container GtkWidget so events will only be sent to
the DOM once.)

Comment 6

[Tomeu Vizoso]

Yes, Sugar's browser is written in python and uses hulahop to embed Mozilla, hulahop is a pygtk widget with facilities to use PyXPCOM.

This means that from the application we cannot directly access Mozilla's internal GtkWidget.

And as Karls says, you should return True when you have handled an _action_ and don't want anybody else be able to act again on that same event. visibility-notify is not an action but a notification so should be always let to propagate.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:stransky, could you have a look please?
For more information, please visit auto_nag documentation.