Autopilot-gtk must not use memory addresses as object ids
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| autopilot-gtk |
Critical
|
Unassigned |
Bug Description
The fact that autopilot-gtk is using object memory address locations as object ids is causing problems with server-side parameter matching, where values outside MININT <-> MAXINT overflow the xpathselect rule.
Related branches
- PS Jenkins bot: Approve (continuous-integration) on 2013-09-17
- Martin Pitt (community): Approve on 2013-09-17
-
Diff: 957 lines (+425/-133)13 files modifieddebian/changelog (+7/-0)
debian/control (+4/-4)
debian/rules (+2/-1)
lib/GtkNode.cpp (+147/-60)
lib/GtkNode.h (+18/-8)
lib/GtkRootNode.cpp (+24/-16)
lib/GtkRootNode.h (+5/-3)
lib/Introspection.cpp (+3/-3)
lib/Variant.cpp (+168/-22)
lib/Variant.h (+3/-1)
lib/autopilot_types.h (+34/-0)
tests/autopilot/tests/test_widget_tree.py (+2/-6)
tests/autopilot/tests/test_xpath_query.py (+8/-9)
Martin Pitt (pitti) wrote : | #1 |
Martin Pitt (pitti) wrote : | #2 |
Ah, I understand now. AFAICS, the easiest option is to just use the
lower 32 bits. This ought to work in practice as the heap is in a
single virtual segment anyway, so as long as we don't create many
hundred million widgets (which we couldn't handle anyway, FWIW) there
should be no collisions.
The alternative would be to use an increasing number like in -Qt.
When I previously wrote "there are no dynamic properties" I forgot
about qdata, which provides something like that. They are not type
save or introspectable, but that isn't necessary. Something like
GQuark OBJ_ID = g_quark_
static guint32 cur_obj_id = 1;
in the ap initialization, and then
g_object_
[...]
guint32 id = (guint32) g_object_get_qdata (my_widget, OBJ_ID);
PS Jenkins bot (ps-jenkins) wrote : | #3 |
Fix committed into lp:autopilot-gtk at revision 53, scheduled for release in autopilot-gtk, milestone Unknown
Changed in autopilot-gtk: | |
status: | Triaged → Fix Committed |
Changed in autopilot-gtk: | |
status: | Fix Committed → Fix Released |
I don't understand that -- refreshing properties of a GObject doesn't change the address of the GObject itself. That would only happen if you destroy e. g. a button and re-create it?