User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110530 Firefox/7.0a1 Build Identifier: Currently we show a url preview, but not the alt tags, I believe we should display these as well. Reproducible: Always

There is an add-on that provides some related functionality: https://addons.mozilla.org/en-US/mobile/addon/show-tooltips/

According to standards/Mozilla convention alt text should only be displayed when the image is not loaded. Title text might be worth finding some way to display.

(In reply to comment #2) > According to standards/Mozilla convention alt text should only be displayed > when the image is not loaded. Title text might be worth finding some way to > display. My general thoughts were that lets say you're on a meta bug and you're looking at dependencies, it's easy to click the wrong link, in those cases where you have a bunch of links close together, it's be nice if you could get visual confirmation when you attempt to open in a new tab.

Possibly wontfix due to #c2, unless we want to morph this into being about the title attribute.

(In reply to comment #4) > Possibly wontfix due to #c2, unless we want to morph this into being about > the title attribute. By all means that makes sense. As this is indeed about links rather than image text.

Matt, is this still a valid bug for a new contributor to be working on? In other words, does this still apply to the Native UI, so that the work done won't be wasted?

(In reply to Josh Matthews [:jdm] from comment #8) > Matt, is this still a valid bug for a new contributor to be working on? In > other words, does this still apply to the Native UI, so that the work done > won't be wasted? Yes, this is still valid. Moving to the Fennec Native product. For anyone interested in working on this, it might be done with a context menu. The code for that is here: https://hg.mozilla.org/mozilla-central/file/ee38392142ed/mobile/android/chrome/content/browser.js#l1137

Matt, I can try taking this up. So, from what I understand, we need the long-press-menu on links to show an option to display the title text. Is it for both titles and images? How do we display the text, menu click > alert-kinda box?

(In reply to Thiyag Krishna (:thiyag) from comment #10) > I can try taking this up. So, from what I understand, we need the > long-press-menu on links to show an option to display the title text. Is it > for both titles and images? Yes, for both links and images. In fact, I think you could make it show up for any HTML element with a "title" attribute. (Then it would automatically work for other common use cases like <abbr> and <imagemap>.) > How do we display the text, menu click > alert-kinda box? Yes, I think that's the most straightforward option and it's what the add-on in comment 1 does (in old versions of Fennec). Displaying the text immediately in the menu popup itself could also be neat, but I think this might not work well with the design of Android's pop-up menus. Adding Madhava to see if the UX team has any comments.

FWIW, I'm working on some changes to the prompt service to allow a second line in the title. Similar (in fact exactly) like what we currently do in the site permissions dialog (Menu->More->Site Permissions). That fix has grown into a much bigger reorganization of the entire PromptService.java though.

Matt, Preliminary patch adding context menu to display the title text for all elements having a title attribute. Currently displaying "No text available." if there is a title attribute which has no content. Please let me know how it looks, If needed, I will update the selector to suppress the menu if there is an empty title attribute. I will add some screenshots as well.

Title dialogs and context menu screenshot, has a screenshot of a really long title as well.

> Displaying the text immediately in the menu popup itself could also be neat, > but I think this might not work well with the design of Android's pop-up > menus. It would be nice in terms of usefulness. We manage to display the URL and simply adding a line above/below that wouldn't detract from the overall design.

Comment on attachment 625877 [details] [diff] [review] Title context menu patch-v1 This is a good start. "Title" should be localized too. However, I just noticed that we already show the link tooltip as the title/caption of the context menu for links. Could we extend this to all elements with titles, rather than add a new menu item? Sorry for not noticing this sooner.

To clarify: this was fixed in bug 697309 for elements that have contest menus, like links and images. I should have noticed this sooner and marked this bug fixed. There's still one case that's not fixed: elements like abbr that don't have any context commands.

(In reply to Matt Brubeck (:mbrubeck) [back on 5/21] from comment #17) > To clarify: this was fixed in bug 697309 for elements that have contest > menus, like links and images. I should have noticed this sooner and marked > this bug fixed. > > There's still one case that's not fixed: elements like abbr that don't have > any context commands. No problem, Matt :) The only thing I noticed was the menu title runs out of space if there are more than two lines of text. Are long title attributes common and do we need to accommodate them?

(In reply to Thiyag Krishna (:thiyag) from comment #18) > No problem, Matt :) The only thing I noticed was the menu title runs out of > space if there are more than two lines of text. Are long title attributes > common and do we need to accommodate them? I don't think they're very common, and I expect the UX team would rather not clutter up the context menu just to support a relatively rare case. (But maybe we could keep that as an add-on for people who want it.) Since the common cases are already fixed, I'm not sure there's any work left to be done for this bug. I'm going to mark this fixed by bug 697309; if anyone wants to propose fixes for the remaining corner cases (long titles, <ABBR> tags) then please file follow-up bugs. Again, I'm sorry to have mistakenly taken your time on this. :( But I hope you learned a bit about Firefox code and will continue writing patches for other bugs!