707917 - Word cloud does not render correctly

Status: RESOLVED INCOMPLETE

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

Description

[Irina Sandu]

Attachment: screenshot

The word cloud at the bottom of zoso.ro does not render correctly (screenshot attached). To reproduce, go to www.zoso.ro and scroll to the bottom of the page, to the word cloud.

Comment 1

[JP Rosevear [:jpr]]

Release blockers.

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

Scott, dbaron thinks this may be a dupe of bug 708187, can you confirm and mark it if it is.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So the word cloud doesn't seem to be on the page anymore.  But if it were I think it probably would have been fixed by bug 708187.  So I'm going to mark it as a duplicate, but if there's still some way to see that content on the blog, I'd be interested in testing.

I'll test on http://web.archive.org/web/20110725144805/http://www.zoso.ro/ though it doesn't have the same styles.

Comment 4

[Irina Sandu]

The word cloud is still available on the page and it still does not render correctly. Attaching screenshot from test on the latest nightly on Galaxy Nexus.

Comment 5

[Irina Sandu]

Attachment: screenshot 2

Comment 6

[Irina Sandu]

Attachment: desktop screenshot

This is how it shows on the desktop.

Comment 7

[Aaron Train [:aaronmt]]

If you look closely you will see an ever so slight variance in the font-sizes of the 'larger' words in the word cloud; but as Irina mentions it nowhere near looks like what you see on Desktop. This kind of defeats the purpose of using the word cloud if font-inflation can't get it right.

Comment 8

[Scott Johnson (:jwir3)]

So, just to give an update on this bug quickly:

The way the font inflation algorithm works, it takes a range of the font sizes on a given page, say 0px (we always start from 0px, even though there aren't any fonts that are actually rendered at 0px) to, for example, 45px. When we inflate the fonts to a minimum size (say we calculate the minimum to be 30px), then we squish the original range of 0px-45px into the range of 30px-45px, trying to maintain some separation between differing font sizes, while at the same time increasing lower font sizes. This means that we have a much finer gradiation than we originally have. In turn, this means that we have less range of difference between font sizes.

What I think is happening in this case is that we don't have enough difference between the font sizes after they are inflated to notice a difference. Unfortunately, this might just be an inherent flaw of the algorithm as it works right now. We can discuss it, and we might be able to come up with a fix, but I'd recommend that we remove this from the blocking list for fennec 1.0.

Comment 9

[Scott Johnson (:jwir3)]

Also, some evidence to support my claim. If you adjust the font-inflation emPerLine property, starting at 60 emPerLine, and gradually move down to 15 emPerLine, you'll notice the fonts start to coalesce so they have a very small range of differences. This, I believe, is because as we move from 60 emPerLine down to 15 emPerLine, we're effectively increasing the minimum font size, and thus decreasing the possible range of differing font sizes available.

Comment 10

[Kevin Brosnan [Ex-Mozilla]]

Setting to re-nom based on comment 8 and 9.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think the original problem reported here was in fact a duplicate, as was marked.  The new problem doesn't seem as serious... and is related to bug 707195.

Comment 12

[Erin Lancaster [:elan]]

To evangelism to follow up. Will work with lmandel for proper tracking.

Comment 13

[Lawrence Mandel [:lmandel] (use needinfo)]

Erin, can you comment on why you think this is an evangelism problem? From the comment stack this issue looks to be due to Fennec's use of font inflation.

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

Lawrence, text that shouldn't be inflated (such as this) can use the text-size-adjust CSS property

https://developer.mozilla.org/en-US/docs/CSS/text-size-adjust

Comment 15

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Brad Lassey [:blassey] from comment #14)
> Lawrence, text that shouldn't be inflated (such as this) can use the
> text-size-adjust CSS property
> 
> https://developer.mozilla.org/en-US/docs/CSS/text-size-adjust

In this case, the site works as designed in the Android stock browser and Chrome. AFAIK, the site does not work in Firefox for Android due to our font inflation implementation. Given the state of the mobile Web and our requests for sites to accommodate Firefox by moving to standard practices, asking a site to add a non standard property in order to support Firefox for Android seems off message for me. I think we either need to decide to fix this use case in our browser or accept that this use case will be broken in our browser.

Comment 16

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: currently screenshot

Comment 17

[:Margaret Leibovic]

Mass change to move Firefox for Android::Readability bugs to block bug 1129033. Filter on readability-mass-move.

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 24 weeks.

Comment 19

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.