GNOME Bugzilla – Bug 447925
Firefox go to next smallest/largest object
Last modified: 2008-07-22 19:28:05 UTC
The specification for 'go prev/next chunk' reads as follows: The letters "o" and "Shift+o" will be used to move between large objects. Large objects can be things such as: headings, paragraphs, and tables. For this feature, links and form controls will not be considered large objects. I interpret to mean that triggering this command will take the user to the next/prev 'chunk', whatever chunk is defined to be. User configuration??? My vision (actually Peter's) was to move to the next smallest/largest object with the idea that size actually does matter :) Hopefully, the larger the screen real estate = more important content. I will post a patch of my idea and will ask the user community for feedback. This feature, like many of the other features where the entire tree must be navigated, will be sluggish on large documents.
Created attachment 90035 [details] [review] first version of go to next smallest/largest object I found it very difficult to use the current locus of focus as a reference point to move to the next smallest/largest object. This was mainly due to problems in defining a container and working around layout tables. Instead, I used the state variable self.currentSizeObj to track the last smallest/largest item navigated to. Now, triggering go to next smallest/largest just moves to the object that is next smaller/larger than self.currentSizeObj. Items of concern and interest: 1) Is this a useful feature? 2) Is self.currentSizeObj being reset at a good location in the code? Should we create a resetStateVars() method? 3) get next/prev chunk has been disabled (code not removed). The key bindings ('o', 'shift + o') now trigger these new methods. 4) outlineAccessible() is used to identify the target accessible. This will be removed when testing is finished.
Aha! I was interpreting the "next" to mean a linear ordering of content (e.g., next/previous). The light has finally dawned on me and I understand this is done in terms of the total screen real-estate covered by an object. This is definitely much different than linear navigation by "chunk", and probably should get its own set of keystrokes (e.g., '+' and '-' -- Mike?). > 1) Is this a useful feature? This is definitely something for our users to answer. I think a good thing to do here would be to ask a question on the orca-users mailing list, pointing them to the patch. If we discover the majority of users cannot apply a patch, then I guess checking it in might be the next thing to do; it's a relatively isolated patch, especially if you just add new keystrokes instead of replacing 'o' and 'Shift+o'. I'm also curious about the navigation method. Is there an assumption here that the area covered by each object is going to be unique to that object? For example, assume there are only 4 objects in a document frame and they all have the same area. Let's call them a, b, c, and d. I'm not sure, but it looks like the navigation would end up jumping to a, then b, then back to a again, skipping c, and d. Is that correct? > 2) Is self.currentSizeObj being reset at a good location in the code? Should we create a > resetStateVars() method? I'm not sure. When one tabs or arrows around the document content should self.currentSizeObj change? If so, what does it change to? Thanks!
> This is definitely much different than linear navigation by "chunk", and > probably should get its own set of keystrokes (e.g., '+' and '-' -- Mike?). I like the new keystrokes and feel that the old navigation by chunk is valuable as well. > This is definitely something for our users to answer. I think a good thing > to do here would be to ask a question on the orca-users mailing list, > pointing them to the patch. Great idea. I will post the question. > I'm also curious about the navigation method ... Your observation is correct and something I did not consider. Although this would be a rare event, it should definitely be coded against. A solution would be to make self.currentSizeObj a list of previously seen objects and compare against all of them. This could easily be accomplished with a set operation (if obj in self.currentSizeObj). > I'm not sure. When one tabs or arrows around the document content should > self.currentSizeObj change? If so, what does it change to? This feature is really only valuable for the first two or three large objects, which are usually menu structures, main content and secondary content. Once the user lands on one of these structures they are certain to continue navigating. A second press should then bring them to the next largest structure and not back to the same structure that they just finished navigating. I feel that self.currentSizeObj should only be reset when the user has changed pages.
Created attachment 90214 [details] [review] second version of go to next smallest/largest object This version takes into account areas that have the same size by keeping a list of previously navigated areas (in descending size) in self.currentSizeObj. This also created an opportunity to increase the performance of goNextLargest() by using the contents of this list.
Added samesizearea.html test page to repository.
I'm having trouble finding areas where this is really useful. Perhaps we should really look more at how to fix the existing object navigation feature. Scott, I'll be around all day if you want to give a call and talk more about this. thanks much
Perhaps we should close this one as Scott has fixed the feature that was to implement the needed functionality.