GNOME Bugzilla – Bug 417001
Need to implement link structural navigation in Firefox
Last modified: 2007-03-15 17:39:56 UTC
According to the Firefox specifications, "The letters "u" and "v" will be used to move between unvisited and visited links." I assume that shift+u and shift+v will also be used. Regardless, this is currently not implemented.
Created attachment 84371 [details] [review] proposed patch This seems to get the job done. It assumes that we do indeed want to use Shift+U and Shift+V in addition to U and V.
This looks pretty good. I have a question about the particular image/link construct being checked for. It the HTML construct one of <a href="foo"><image yadda yadda/></a>? If so, do we have the potential to run into other things such as <a href="foo"><h1>How to write bad HTML</h1></a>? If so, how does this patch work with those?
> If so, how does this patch work with those? Sometimes it gets stuck. :-( Thanks for catching that!! So I guess what we want to do is see if the currentObject has a link in its ancestry. After all, you could do something like: <a href="foo"><div><blockquote><h1>How to write bad HTML</h1><p>Yadda, yadda, yadda <img src="blah" alt="blah" /></p></blockquote></div></a> I made the check-the-ancestry change and it seemed to get the job done. However, in the process I discovered a different issue with items embedded in a link -- at least images: If you use U/V to move to an image which is a link and then press Tab, you don't move to the next link w.r.t. the caretContext; you move to the next link w.r.t. whatever link you were on prior to moving to that image. If you press U/V instead of Tab, you move as you'd expect. Still investigating....
Created attachment 84616 [details] [review] revised version: check ancestry of object to see if we're in a link Patch to address the scenario Will pointed out. I have since been able to reproduce the linked image focus issue (see previous comment) independent of this patch by using Up/Down Arrow. Still haven't worked out what is going on there, but it's a separate issue/bug.
> revised version: check ancestry of object to see if we're in a link Great! There's also a getContainingLink method that might be useful and also has some defensive code in it (i.e., prevents infinite loops if obj.parent == obj, which we've run into before).
Created attachment 84646 [details] [review] revised version redux: use exisiting method to check ancestry (D'oh!) Yup, I saw getContainingLink() in another context and promptly forgot about it. My bad! Hopefully third time is charm. Thanks!!
> Hopefully third time is charm. Thanks!! Charming. :-) I say commit and close this as FIXED.
Phew! :-) Thanks and done!