Open Bug 738549 Opened 12 years ago Updated 2 years ago

[Bookmarks Library] signal name `selection_changed' is invalid for instance `xxxxxxxx`

Categories

(Core :: Disability Access APIs, defect)

x86
Solaris
defect

Tracking

()

People

(Reporter: ginnchen+exoracle, Unassigned, Mentored)

Details

(Whiteboard: [lang=c++])

Menu->Bookmarks->Show All Bookmarks

Got these message in terminal:

GLib-GObject-WARNING **: gsignal.c:3081: signal name `selection_changed' is invalid for instance `xxxxxxxx`

Select "Bookmarks Toolbar" in the right panel, select "Today" in the left panel.
Got the warning again.

The event is emitted from nsAccessibleWrap::FirePlatformEvent().

"this" is nsXULTreeGridRowAccessible, it doesn't have Selection interface, so it doesn't have the event.
Should we fire the event to its parent instead?
It sounds like you need to fix nsIAccessibleEvent::EVENT_SELECTION_WITHIN case in atk/nsAccessilbeWrap.cpp same way as EVENT_SELECTION_REMOVE, i.e. use selChangeEvent->Widget() as a target.
Whiteboard: [good first bug][mentor=hub@mozilla.com][lang=c++]
(In reply to alexander :surkov from comment #1)
> It sounds like you need to fix nsIAccessibleEvent::EVENT_SELECTION_WITHIN
> case in atk/nsAccessilbeWrap.cpp same way as EVENT_SELECTION_REMOVE, i.e.
> use selChangeEvent->Widget() as a target.

uh, the downcast of an AccEvent for SELECTION_WITHIN won't always work, we sometimes just have a plane AccEvent in these cases see nsRootAccessible.cpp:482
(In reply to Trevor Saunders (:tbsaunde) from comment #2)
> (In reply to alexander :surkov from comment #1)
> > It sounds like you need to fix nsIAccessibleEvent::EVENT_SELECTION_WITHIN
> > case in atk/nsAccessilbeWrap.cpp same way as EVENT_SELECTION_REMOVE, i.e.
> > use selChangeEvent->Widget() as a target.
> 
> uh, the downcast of an AccEvent for SELECTION_WITHIN won't always work, we
> sometimes just have a plane AccEvent in these cases see
> nsRootAccessible.cpp:482

oh, right. so we can do a hack:
1) downcast event to AccSelChangeEvent and if it's successful then do selChangeEvent->Widget()
2) otherwise do event->GetAccessible()
> 2) otherwise do event->GetAccessible()

I  think we actually want event->GetAccesible()->Widget no?
(In reply to Trevor Saunders (:tbsaunde) from comment #4)
> > 2) otherwise do event->GetAccessible()
> 
> I  think we actually want event->GetAccesible()->Widget no?

it sounds we need to fix nsRootAccessible.cpp:482 to fire selection_within event for tree accessible (not for tree item as we do), that's consistent to AccSelChangeEvent.
(In reply to alexander :surkov from comment #5)
> (In reply to Trevor Saunders (:tbsaunde) from comment #4)
> > > 2) otherwise do event->GetAccessible()
> > 
> > I  think we actually want event->GetAccesible()->Widget no?
> 
> it sounds we need to fix nsRootAccessible.cpp:482 to fire selection_within
> event for tree accessible (not for tree item as we do), that's consistent to
> AccSelChangeEvent.

I think that'd work, it'd be nice if we stopped using dom events while we're there, but not really necessary
Hi, has this bug been assigned? If not can I work on it? 

-Debkanya Mazumder
You can! Do you have your development environment set up, as per here:

https://developer.mozilla.org/en-US/docs/Introduction
Mentor: hub
Whiteboard: [good first bug][mentor=hub@mozilla.com][lang=c++] → [good first bug][lang=c++]
I'm seeing this message spamming my session log after upgrading TB from 30.0 b1 -> b3.

juuli 20 01:39:27 xps14 gnome-session[1303]: (thunderbird:3458): GLib-GObject-WARNING **: /mnt/datapool/tmp/portage/dev-libs/glib-2.38.2/work/glib-2.38.2/gobject/gsignal.c:3431: signal name 'selection_changed' is invalid for instance '0x7f5de8826d40' of type 'MaiAtkType3'
hello, is somebody working on this bug because i would like to work on this bug, this would be my first bug so i might need some extra guidance debugging it. thanks!
Can I please be assigned for this bug? 
This will be my first bug.
Ok, lots of interest here; Does somebody have a tentative first try at a patch?
Hi, 

This bug has current status assigned to nobody?

I'd like to take a look at this if that is the case as my first C++ bug to look at for Mozilla (actually my first actual open source work for anyone).

I'm using a mac OSX for dev, presumably I can still effectively test this?  
Any pointers in process I need to go through if assigned will be much appreciated.
Flags: needinfo?(hub)
This is a Gtk issue (ie Linux), so MacOS won't help here.
Flags: needinfo?(hub)
I want to work on this bug as my first bug. Can anyone please help me how should I go about solving it.
I want to work on this bug as my first bug. Can anyone please help me how should I go about solving it.
I'm undergraduate at University of Peradeniya. I like to work on this bug.But I did not have any idea to how to start to fix the bug.Can I know the where is the bug is?
this one probably shouldn't be listed in good-first-bugs, there's bunch of issues to fix besides the original reported issue (see comment #6).

But if anyone is willing to work on it, I'd happy to answer questions.
Whiteboard: [good first bug][lang=c++] → [lang=c++]
here's some updated info for two issue in case if anyone is interested (each of them deserves a separate bug)

1) replace DOM events on direct notifications

a) add a method to nsAccessibilityService to move all stuff from [1]
b) call it from tree selection class [2]
you can follow this work to have a better idea of how it may look like [3]

[1] https://dxr.mozilla.org/mozilla-central/rev/4c05938a64a7fde3ac2d7f4493aee1c5f2ad8a0a/accessible/generic/RootAccessible.cpp#361
[2] https://dxr.mozilla.org/mozilla-central/source/layout/xul/tree/nsTreeSelection.cpp#823
[3] https://hg.mozilla.org/mozilla-central/rev/f6b9554b2b1c

2) make XUL tree accessible to fire AccSelChangeEvent
a) modify AccSelChangeEvent class to take new 'eSelectionWithin' flag
b) make sure EventQueue works well with new flag 
c) use it in RootAccessible handler (see #1)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.