768291 - Image title is shown truncated in context menu

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect, P5)

Description

[François Marier [:francois]]

Attachment: Fennec Nightly screenshot of XKCD alt text

Web page or screen you were on when you saw the issue: 

http://xkcd.com/1068/

Steps to reproduce:
1. Visit above URL
2. Tap and hold image to see partial alt text

What you expected:

Some way of seeing the full alt text. I realize that fixing the XKCD alt text is not the highest priority :) but I suspect this affects other sites too.

Fennec Nightly 16.0a1 2012-06-25

Comment 1

[Michael LoPiccolo (:milo)]

For any other webcomic readers who find this page, this addon works well enough for me: https://addons.mozilla.org/en-US/android/addon/show-tooltips-for-android/

Comment 3

[Sebastian Kaspari (:sebastian; :pocmo)]

For the sake of XKCD: This needs to be fixed. I already have a basic patch ready. Need to finalize it. :)

Comment 4

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: xkcd_titles_prompt.png

This screenshots show the new implementation. The title text size is a bit smaller to read more at a time. In addition to that the height can grow to up to 100dp. If even more space is needed then the title will be scrollable.

The screenshot compares the current and new implementation with a short and (previously) matching title, an average XKCD title and a ridicolous long title.

@Anthony: What do you think?

Comment 5

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Comment on attachment 8646888 [details]
xkcd_titles_prompt.png

This is interesting. 

But I think it's a bit overkill to be honest. The dialog title is not really meant to handle these long (almost paragraph length) strings. It should be short and scan-able. I think alt tags were designed to be short, and brief in nature as well. 

While I can see the advantages of showing the whole alt tag, I'm hesitant to add complexity in our product just to handle these cases.

Plus I think the web is getting better with these things generally speaking, so I'm ok with WONTFIX-ing here.

Comment 6

[Sebastian Kaspari (:sebastian; :pocmo)]

NI-ing Anthony again after IRC debate.. ;)

Comment 7

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

After clarifying that it should be the Title, I can see how this would be useful.

Sebastian, can we try and keep the height the same and maintain the side padding as well? but just change the font size if it goes past the two lines.

For type, what's the default size and family we're using right now? I can offer our alternate type specs to keep consistent.

And whats the height that we currently have the dialog title at? We might need to increase this depending on what the new type looks like.

Comment 8

[Jan Henning [:JanH]]

Sorry for introducing potential further scope creep, but I've just realised that links can have a "title" attribute as well, as e.g. used extensively here on Bugzilla. Should truncation be handled for link titles as well?

Comment 9

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Anthony Lam (:antlam) from comment #7)
> Sebastian, can we try and keep the height the same and maintain the side
> padding as well? but just change the font size if it goes past the two lines.

The problem here is: It's very hard to know that this overflow is happening in advance. We can try to find a good algorithm, maybe just using the character count, but this will not cover all cases (very long titles). Before limiting the max height to 100dp I've let the view grow indefinitely (= no scrolling).

> For type, what's the default size and family we're using right now? I can
> offer our alternate type specs to keep consistent.
> 
> And whats the height that we currently have the dialog title at? We might
> need to increase this depending on what the new type looks like.

Right now this seems to be not modified by us. Looking at the style definitions of 21+ (Material), here are some numbers:

* maxLines: 2
* alert_dialog_title_height: 64dip
* dialog_padding_material 24dp
* dialog_padding_top_material: 18dp
* fontFamily: sans-serif-medium</
* textSize: 20sp

(In reply to JanH from comment #8)
> Sorry for introducing potential further scope creep, but I've just realised
> that links can have a "title" attribute as well, as e.g. used extensively
> here on Bugzilla. Should truncation be handled for link titles as well?

Good catch. In combination with bug 1194269 I wonder if we can find a good solution that will cover all three things.

Comment 10

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Sebastian Kaspari (:sebastian) from comment #9)
> (In reply to Anthony Lam (:antlam) from comment #7)
> > Sebastian, can we try and keep the height the same and maintain the side
> > padding as well? but just change the font size if it goes past the two lines.
> 
> The problem here is: It's very hard to know that this overflow is happening
> in advance. We can try to find a good algorithm, maybe just using the
> character count, but this will not cover all cases (very long titles).

I think this is a good place to start. It's not perfect, but in those edge cases, the experience would just be similar to the current anyways (truncated).

What about the side padding? It's a bit awkward that it changes I think.

> Before limiting the max height to 100dp I've let the view grow indefinitely
> (= no scrolling).
> 
> > For type, what's the default size and family we're using right now? I can
> > offer our alternate type specs to keep consistent.
> > 
> > And whats the height that we currently have the dialog title at? We might
> > need to increase this depending on what the new type looks like.
> 
> Right now this seems to be not modified by us. Looking at the style
> definitions of 21+ (Material), here are some numbers:
> 
> * maxLines: 2
> * alert_dialog_title_height: 64dip
> * dialog_padding_material 24dp
> * dialog_padding_top_material: 18dp
> * fontFamily: sans-serif-medium</
> * textSize: 20sp

I see here it's set at 20sp. Is that before, or after the shrinking of the font size happens?

Comment 11

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Anthony Lam (:antlam) from comment #10)
> What about the side padding? It's a bit awkward that it changes I think.

We can keep it. I was just trying to get more space. ;)


(In reply to Anthony Lam (:antlam) from comment #10)
> > * textSize: 20sp
> 
> I see here it's set at 20sp. Is that before, or after the shrinking of the
> font size happens?

This is Android's size for a dialog title. So we can start at this size and see how much we want to reduce it from there.

Comment 12

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Sebastian Kaspari (:sebastian) from comment #11)
> We can keep it. I was just trying to get more space. ;)

Great, thanks! 

> (In reply to Anthony Lam (:antlam) from comment #10)
> This is Android's size for a dialog title. So we can start at this size and
> see how much we want to reduce it from there.

Ah, I thought so! I was also wondering what size the type in the screen shots were at (after they were shrunk). This means we can set it as another value then? We should probably keep it as the same fontfamily though.

Can we try 14sp? same family, same side padding :)

Comment 13

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Anthony Lam (:antlam) from comment #12)
> Can we try 14sp? same family, same side padding :)

Alright. I'll prepare a new patch.

Comment 14

[Sebastian Kaspari (:sebastian; :pocmo)]

My list of assigned bugs is overflowing. This has the lowest priority. But I'd mentor if someone wants to pick it up.

Comment 18

[Linus Kardell]

Now, you can no longer use the aforementioned extension as a workaround, due to Firefox breaking all old extensions, so this ought to increase in priority.

Comment 20

[Ricky]

Such a minor thing to remain unresolved since this bug was apparently first reported 6 years ago. Others, like me until I found an add-on which fixes this ("Mobile Tooltip"), will switch to Chrome or another browser because they want to do something simple like view the full text. This is particularly true for casual Firefox users who don't even know about extensions/add-ons. I believe in Firefox, guys. Let's close the lid on this one soon, please.

Comment 21

[singhnsk]

I agree with Ricky. While, I do understand that webmasters should not use such long title/alt tags, we know that some do use them. There must be a way to handle these. The implementation doesn't seem like a too hard task either. We just need to add a touch-scroller when the text goes too long to fit in the designated area instead of cutting it off with ellipsis. Chrome handles that well and our dear Firefox should do it too.

I hope this will be fixed and closed.

Comment 22

[Dirkjan Ochtman (:djc)]

Is someone willing to mentor this? It just seems sad for this to keep sitting here, preventing Firefox/Android from being great for consumers of these kinds of web comics (it's not just xkcd itself).

Comment 23

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 25

[Emily Bourke]

(In reply to Sebastian Kaspari (:sebastian; :pocmo) from comment #14)

My list of assigned bugs is overflowing. This has the lowest priority. But
I'd mentor if someone wants to pick it up.

Sebastian, are you still willing to mentor someone? I’m up for taking this on if so.

Comment 26

[Kevin Brosnan [Ex-Mozilla]]

Firefox for Android development is largely complete. It will get security updates on the 68 ESR cycle.

The same issue for Android Components exists. If you have some free time looking at that issue would be a way forward. Info on contributing to the Android Components project can be found at https://github.com/mozilla-mobile/android-components#getting-involved Thank you for your interest.