GNOME Bugzilla – Bug 539056
Orca should give the user feedback when pressing delete on a placeholder in Impress
Last modified: 2018-02-08 12:56:03 UTC
1. Create a slide with a title and text (i.e. bulleted list) placeholder. 2. Add some text to each placeholder. 3. Press Tab to move focus to a placeholder and press Delete. This will cause all of the contents of the placeholder to be deleted and the placeholder to give up focus, but the placeholder will still be on the slide. 4. Press Tab until you return to the now-empty placeholder from step 3. Press Delete. Because the placeholder is empty at the time Delete was pressed, the placeholder will be physically removed from the slide. Expected results: After step 3 and after step 4, Orca would say something to indicate what had taken place. Actual results: Orca speaks nothing after step 3 and nothing after step 4. I'm not sure what the something is which we should say. That's why we have a UI Guy <smile>, and why I'm putting his name on the summary.
For step 3 how about speak/braille "placeholder contents deleted" and for step 4 "placeholder deleted. If anything has focus after these actions we should speak the new focus after speaking the above messages.
Created attachment 113271 [details] Sample presentation I used to test this problem.
Created attachment 113273 [details] Orca debug log generated whilst testing this problem. Using the following steps with the attached presentation (not a spreadsheet :-) ), it can be shown that we are not getting any accessibility events from OOo when we delete either the contents of the placeholder or the placeholder itself. I will file YAOOOB and block this one against it. Steps to reproduce. 1/ Start Orca. 2/ Start ooimpress with the attached presentation (foo2.odp). Focus is initially on the scroll pane containing the current slide of the presentation. 3/ Tab to the first placeholder. 4/ Press Delete to delete the contents of the placeholder. 5/ It's not obvious where focus is al this point, so I pressed Tab to move focus to the second placeholder, then Shift-Tab to move it back to the first placeholder. 6/ Press Delete to delete the placeholder. From the attached Orca debug log, pressed the Delete in step 4 is at line 430. Pressin the Delete in step 6 is at line 668.
I've opened OOo issue #90993 http://www.openoffice.org/issues/show_bug.cgi?id=90993 against this problem.
I was just looking at this. We get object:children-changed:remove events. We're just not listening (and hence not logging). :-) It says in _processObjectEvent that we don't like these events. If we get bombarded by them, I can understand our not liking them. But that aside, the deletion of a child seems appropriate for object:children-changed:remove. What event(s) should we be getting (asking for) instead/in addition?
(In reply to comment #5) > I was just looking at this. We get object:children-changed:remove events. We're > just not listening (and hence not logging). :-) > > It says in _processObjectEvent that we don't like these events. If we get > bombarded by them, I can understand our not liking them. But that aside, the > deletion of a child seems appropriate for object:children-changed:remove. What > event(s) should we be getting (asking for) instead/in addition? We generally do not like the object:children-changed:remove events because they involve working with children that are dead. When we process the events for them synchronously, we may or may not be able to get to their info. When we process the events for them asynchronously, they may likely have gone away, regardless of the ref count we're holding for them. That's been my experience, anyway. So, for other events? I'm not sure. I'm not seeing anything really apparent in accerciser. So...let's assume we get the objec:children-changed:remove events. How would we turn those into meaningful presentations?
(In reply to comment #6) > So, for other events? I'm not sure. I'm not seeing anything really apparent > in accerciser. So...let's assume we get the objec:children-changed:remove > events. How would we turn those into meaningful presentations? Alternatively, what other events would we desire to get? text deletion? caret movement? object focus?
(In reply to comment #6) > We generally do not like the object:children-changed:remove events because they > involve working with children that are dead. Aha. That make sense. Thanks for the explanation! But.... I thought this was one of the reasons we created -- or modified, I forget now -- isSameObject: because an application or toolkit might decide to kill Accessibles which we were holding onto and which we might need to examine/compare (by name, by extents, etc.). If we combine the use of isSameObject with a protective try/except, shouldn't that allow us to safely compare the zombie child with.... well.... the same zombie child? :-) Which brings me to: > So...let's assume we get the object:children-changed:remove > events. How would we turn those into meaningful presentations? The case in question is that we've moved to a placeholder (which became our locusOfFocus) and deleted it (which caused the event in question to be emitted with the deleted placeholder contained in the event's any_data). So.... If the locusOfFocus and the event.any_data pass the isSameObject test, we know that the proverbial rug has been pulled out from under us. If that rug also passes a simple isDesiredFocusedItem test confirming that it is (very likely) a placeholder, we announce that a placeholder has been deleted. Note that I still have to work out how we can best distinguish the deletion of contents from the physical removal of the placeholder itself. HOWEVER, what I describe above *seems* to work. At least at the proof-of-concept level.... (In reply to comment #7) > Alternatively, what other events would we desire to get? That's the kicker.... I don't see any more promising event candidates either. :-( And while I totally see and agree with your point about the hazard of zombie children, I also totally see the logic behind this event being emitted: objects are being deleted from the parent slide. That, to me, says object:children-changed:remove. > text deletion? Maybe.... But: 1. What if the placeholder doesn't hold text, but instead holds an image or a chart/graph or a video? In those instances, no text is being deleted; an object still is. 2. Would that introduce more work for us: yet another thing to check for when looking at the deletion of text, trying to figure out why that text was deleted and what we should present as a result? > caret movement? When you Tab to a placeholder (or press Escape having been inside one) you don't have an active caret -- even if that placeholder does contain text. You essentially have a focus rectangle. When you then delete that placeholder, you do not gain an active caret as a result. > object focus? When you delete the placeholder, nothing seems to have focus. See Rich's point 5 in comment 3. That's a usability issue I think and perhaps YAOOB. But given that focus is being given up to seemingly nothing, I'm not sure how a focus event could help us. So.... I dunno... :-( I'm totally open to suggestions on this one.
I'm removing the blocked status of this bug. The blocking bug was closed out as WORKSFORME with the following comment: ------- Additional comments from af Tue Sep 15 10:54:58 +0000 2009 ------- As mentioned in the gnome issue that is referenced above the relevant notifications are alreadymade: The deletion of the shape and the creation of a new placeholder shape in its place are properly notified by child events. As far as I know there is no way to represent the relationship between the two shapes (one of the two is no longer a member of the accessibility hierarchy.) But then again the geometrical information together with the temporal proximity of the child events may be enough to detect it anyway. Because of all this and because I do not know what events else to broadcast I change the resolution of this issue to WORKSFORME. ------------ So we either need to work with the events we do get, or we need to ask for a specific event, relationship, whatever.
Marking as depends on bug 591925: * Given the (unknown/unverified) risk associated with our attempting to play with zombie children, I am thinking the thing to do is to make it really hard for other scripts to accidentally encounter the undead. We can do this via the new skipObjectEvent() method created in script.py in the proposed fix for bug 591925. * When trying to figure out whether or not a placeholder had just been deleted, looking at the events which led up to the object:children-changed:remove event might prove to be valuable. In which case we need those old events. The fix for bug 591925 provides them.