1037905 - Images of KB articles can not be seen from Firefox OS versions >= 1.4 due to SUMO UA sniffing

Status: RESOLVED FIXED

(support.mozilla.org :: Knowledge Base Software, task, P3)

Description

[Safwan Rahman (:safwan)]

Attachment: screenshot of not loading images!

User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 (Nightly/Aurora)
Build ID: 20140703144438

Steps to reproduce:

Open a KB Article from Firefox OS device.

 Like: https://support.mozilla.org/en-US/kb/forum-response-import-contacts-firefox-os


Actual results:

The article is showing well but the images of the article like Icons are not showing.


Expected results:

All the images of the article would load and can be seen with the writing. Like icon

Comment 1

[Andrew Truong [:feer56] [:andrewtruong] [:atruong]]

This only seems to affect common response articles; able to reproduce on Keon.

Comment 2

[Safwan Rahman (:safwan)]

Andrew,
Thinks for verifification. Does it happen only in forum responses or happen in other articles also?

It happens on every KB article I am trying to see from keon. Like the following KB article.

https://support.mozilla.org/en-US/kb/add-manage-and-share-contacts-firefox-os?&mobile=1

Comment 3

[guigs [:guigs] PST (please needinfo me!)]

Looks like 1.3 is not affected, but the notation is definately not working: [[Image:Gray FxOS settings gear]]]

Comment 4

[Ralph Daub [:rdaub]]

Attachment: works on Fireweb v1.1

The article works as expected on the LG Fireweb v1.1.

Safwan, can you share which phone model and Firefox OS version you are testing this on?

Thanks,
- Ralph

Comment 5

[Safwan Rahman (:safwan)]

Hi Ralph, I am facing this problem from Keon running in Firefox OS 2.0.  I don't know if this problem is also happening in other versions. But I wonder, if it is a browser problem or support site problem!

@Topal can you please confirm where is the bug? Support site or Firefox Browser of Firefox OS V 2.0

Comment 6

[Kadir Topal [:atopal]]

I have a Flame with 1.3 here, and it's working fine. Unfortunately I don't yet have 2.0 working on any phone. That said, 2.0 is still not final as far as I know, so maybe an issue with the browser?

Comment 7

[Andrew Truong [:feer56] [:andrewtruong] [:atruong]]

Kinda sketchy with my device so I can't say if it's really affecting me.

Comment 8

[Safwan Rahman (:safwan)]

The problem is not happening in the KB of Firefox for Android. When open any KB of Firefox or Firefox for Android, all the images are loading well. But when try to load the KB Article about Firefox OS, the problem happens. 

Images of KB articles about Firefox OS are not loading from Firefox OS version 2.0

Comment 9

[Michael Cooper [:mythmon]]

I can see the images in a Firefox OS 2.0 simulator. I have access to a Flame running 2.0 as well, I will try and reproduce there as well.

Comment 10

[bhavana bajaj [:bajaj]]

Leaving NI on Mike to get help here.

Comment 11

[Gregor Wagner [:gwagner]]

Can we get some help from QA here and see if this is a regression?

Comment 12

[Jason Smith [:jsmith]]

comment 4 is implying that this is likely not a web-based regression, as this works on 1.1. We can confirm this through branch checks, but I'm moving this back to FxOS for now under the assumption that this is a gecko bug.

Comment 13

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue does occur in 2.0 Flame, 2.1 Flame, Flame 1.4, and Buri 2.1.  

Environmental Variables:
Device: Flame 2.0
BuildID: 20140720184018
Gaia: 8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko: 4bd4b0ae7bbe
Version: 32.0a2 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Environmental Variables:
Device: Flame Master
BuildID: 20140721055837
Gaia: Unknown
Gecko: 0dc711216018
Version: 33.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Environmental Variables:
Device: Flame 1.4
BuildID: 20140718081451
Gaia: 621d152f89347c79619aa909ad62cc2ac9d3ab5b
Gecko: 989db90b4457
Version: 30.0 (1.4) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Environmental Variables:
Device: Buri Master
BuildID: 20140721055837
Gaia: Unknown
Gecko: 0dc711216018
Version: 33.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

The icons do not show up when viewing the article



This issue does not occur on Buri 1.3.

Environmental Variables:
Device: Buri 1.3
BuildID: 20140718005150
Gaia: 23f55be856cef53c6604a6fe4aeb09061afbc897
Gecko: 9d5426c98678
Version: 28.0 (1.3) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

The icons show up when viewing the article.

Comment 14

[Michael Cooper [:mythmon]]

:JMercado nice work! I also tried to reproduce this on a Flame running 2.0 (Boot2Gecko 2.0.0.0-prerelease) and could not reproduce the problem either.

Comment 15

[Safwan Rahman (:safwan)]

Thanks for reproducing in Flame 1.4, 2.0 and 2.1.
Things to be noted about this bug.
1. This problem occures only while loading KB article about Firefox OS. This problem doesn't occure while loading non Firefox OS related articles.
2. All of the images of Non Firefox OS related articles are loading fine from Keon, Firefox OS 2.0. Like the following article

https://support.mozilla.org/en-US/kb/get-started-firefox-overview-main-features

All of the images of above article is loading well from Firefox OS.

Now fact is, does it a site issue bug or a gecko bug. I don't think its a gecko bug because if it was a gecko bug, the images  of Non Firefox OS related article also would not load.

@Jayme: will you please also check the above mentioned article. Does the images load in Flame?

Comment 16

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

(In reply to Safwan Rahman from comment #15)
> Thanks for reproducing in Flame 1.4, 2.0 and 2.1.
> Things to be noted about this bug.
> 1. This problem occures only while loading KB article about Firefox OS. This
> problem doesn't occure while loading non Firefox OS related articles.
> 2. All of the images of Non Firefox OS related articles are loading fine
> from Keon, Firefox OS 2.0. Like the following article
> 
> https://support.mozilla.org/en-US/kb/get-started-firefox-overview-main-
> features
> 
> All of the images of above article is loading well from Firefox OS.
> 
> Now fact is, does it a site issue bug or a gecko bug. I don't think its a
> gecko bug because if it was a gecko bug, the images  of Non Firefox OS
> related article also would not load.
> 
> @Jayme: will you please also check the above mentioned article. Does the
> images load in Flame?

The images do load on the above article on the latest 2.1 Flame.

Environmental Variables:
Device: Flame Master
BuildID: 20140722033326
Gaia: e423c3be8d19c9a8a5ae2571f499c36dc6b0df89
Gecko: 6f702709fab6
Version: 34.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 17

[Jason Smith [:jsmith]]

Triage is +ing this for the fact that this is a regression in gecko outside of control of the app in SUMO. I'm not 100% of the root cause here without a window, but I'll try graphics first.

Comment 18

[Joshua Mitchell (Inactive)]

removing triage flag, regression-window still required. 

Note to QA-Wanted: Window is probably out of range for Flame (occurs in earliest build) so we will probably need to do this on Buri.

Comment 19

[Milan Sreckovic [:milan] (needinfo for best results)]

Leaving unassigned while it's unconfirmed/without regression range.

Comment 20

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue was a little hard to narrow down because it was fixed for a short bit on Central during 1.3.  This issue was fixed around 10/29/2014 and remained so as long on 1.3 even through the aurora and b2g28 branches.  The issue reemerged on the first Central build that moved to 1.4.  I have included the windows and pushlogs for both issues.

We do not have access to B2g-inbound or Mozilla inbound as far back as these windows were (our database has builds for these branches beginning at the end of February/beginning of March respectively) so further tightening these windows was not possible.

Where it gets fixed Regression Window:

Last Broken 
Environmental Variables:
Device: Buri Master
BuildID: 20131028040200
Gaia: 31c260b5c853fe78d6bf44c6aeec52a651c3f025
Gecko: 59ff3a2a708a
Version: 27.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:27.0) Gecko/27.0 Firefox/27.0

First Working 
Environmental Variables:
Device: Buri Master
BuildID: 20131029040205
Gaia: 92c097fd7ac9886f937d9decb0e03ab673deaa1b
Gecko: 518f5bff0ae4
Version: 28.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

Last Broken gaia / First Working gecko - Issue does NOT occur
Gaia: 31c260b5c853fe78d6bf44c6aeec52a651c3f025
Gecko: 518f5bff0ae4

First Working gaia / Last Broken gekko - Issue DOES occur
Gaia: 92c097fd7ac9886f937d9decb0e03ab673deaa1b
Gecko: 59ff3a2a708a


Gecko Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=59ff3a2a708a&tochange=518f5bff0ae4





Where it breaks  Regression Window

Last working 
Environmental Variables:
Device: Buri Master
BuildID: 20131209053402
Gaia: 1d45d1dc3201059d5c8f2efdeb92c04576d8e161
Gecko: 9f12a9fab080
Version: 28.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0


First Broken 
Environmental Variables:
Device: Buri Master
BuildID: 20131210040206
Gaia: c952e2756c03eceb4de6a3eba15651741a62f9e8
Gecko: df82be9d89a5
Version: 29.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:29.0) Gecko/29.0 Firefox/29.0


Last working gaia / First broken gecko - Issue DOES occur
Gaia: 1d45d1dc3201059d5c8f2efdeb92c04576d8e161
Gecko: df82be9d89a5

First broken gaia / Last working gecko - Issue does NOT occur
Gaia: c952e2756c03eceb4de6a3eba15651741a62f9e8
Gecko: 9f12a9fab080

Gecko Pushlog:  http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f12a9fab080&tochange=df82be9d89a5

Comment 21

[Joshua Mitchell (Inactive)]

I dug through these pushlogs as best I could but they are pretty huge (as the reporter explained). 

The only thing I could find in the first pushlog (the one where the issue become temporarily fixed) was bug 926605 which seemed to deal with icons / images. 

I'm hoping someone can make something of these; perhaps there is a tool that can compare the two pushlogs to see what might have reverted in the 2nd.



NI Jason because I was not able to determine a cause and NI the associated dev

Comment 22

[Jason Smith [:jsmith]]

Milan - Can you have someone from your team look at the push log here to see if anything gfx related could be the cause? If there isn't any gfx cause, can you suggest a different Bugzilla component here?

Comment 23

[Milan Sreckovic [:milan] (needinfo for best results)]

Sure, let me look a bit. Perhaps interestingly enough, it works in the 2.0 emulator, but fails on the phone, even when asking for the desktop site.

Comment 24

[Milan Sreckovic [:milan] (needinfo for best results)]

Pointing the browser to the images in question directly (https://support.cdn.mozilla.net/media/uploads/gallery/images/2013-10-10-14-03-47-4136a9.png) displays it correctly.

Comment 25

[Peter Chang[:pchang]]

The pages works for b2g desktop from master.I guess this maybe related to graphic buffer.

Comment 26

[Chiajung Hung [:chiajung]]

Its related to layout...

I can find nsDisplayImage with size 1x1 or 2x2 in this page,
If we switch to PC version, and zoom it to largest possible, we can find a small gray rectangle there...

Comment 27

[Chiajung Hung [:chiajung]]

Jet,
Can you help comment on this?

Comment 28

[Jet Villegas (inactive)]

We've reproduced the issue on trunk and confirmed the regression from 1.3. David Baron is looking into it and will post his findings here.

Comment 29

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

So I think the basic problem here is that there's a script error.

These images are represented in the markup in this form:

<img alt="contacts app" class="wiki-image frameless lazy" data-original-src="//support.cdn.mozilla.net/media/uploads/gallery/images/2013-10-10-14-03-47-4136a9.png" src="//support.cdn.mozilla.net/static/img/placeholder.gif" title="">

and then it's the job of script that's linked from the bottom of the page to fix them up to be something useful.


When earlier script has an error, presumably this breaks.  The JS error that I see is:

[JavaScript Error: "TypeError: k is undefined" {file: "https://support.cdn.mozilla.net/static/js/mobile/wiki-min.js?build=90ed47f" line: 1}]

(When I download the page and mess with the markup in ways that would break the script, I also see the bug on desktop.)

Comment 30

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

If I use ./edit-prefs.sh in the B2G tree to add:

user_pref("general.useragent.override", "Mozilla/5.0 (Mobile; rv:26.0) Gecko/26.0 Firefox/26.0");

to my Firefox OS phone, then the images in https://support.mozilla.org/en-US/kb/forum-response-import-contacts-firefox-os start working again.

So this is an MDN UA sniffing bug.

Comment 31

[Michael Cooper [:mythmon]]

This was originally a SUMO bug, not an MDN bug. I haven't looked closely yet, but my money is on a problem with our "show for" system, since that is the biggest UA-using javascript component we have.

Comment 32

[Safwan Rahman (:safwan)]

From the beginning of the bug, I was saying that it is a SUMO site bug. because articles about Firefox OS only affected this issue. But, other was not having this issue.

Comment 33

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

Oops, sorry, not sure why I'm getting SUMO and MDN mixed up today.


One other point to note is that the reason I tried the UA string was that I noticed one change in the first pushlog from comment 20 was:
https://hg.mozilla.org/mozilla-central/rev/f1010aef5c03
and furthermore, one change from the second pushlog from comment 20 was:
https://hg.mozilla.org/mozilla-central/rev/49527888043b

Complete bisection might have been a more efficient way of finding the problem here, especially if more than one build per day had been retained (avoiding the need to do as many intermediate builds).

Comment 34

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

Also, from looking at the script, the function containing an object with the property:

dataGeckoToFxOS:{18:1,18.1:1.1,26:1.2,28:1.3}

seems likely to be suspicious.

Comment 35

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

Oh, and final (I hope) comment:  While knowing the B2G version correctly would be nice, the real problem here is that the script is throwing an exception when the sniffing doesn't know it, which is breaking other features.  Fixing both (1) exception on failure of version detection and (2) the version detection would be nice, but the real problem here is (1), which is a sign of bad UA sniffing.

Comment 36

[Jason Smith [:jsmith]]

Clearing the blocking flag here since this is a site bug, not a Gaia/gecko bug per the above comments.

Comment 37

[Michael Cooper [:mythmon]]

Adding SUMO sprint metadata and putting it into our next sprint.

Comment 38

[Safwan Rahman (:safwan)]

As Firefox OS will launch in Bangladesh with Telenor. So far I understand from the consistency point of view, I believe our partner Telenor will launch here Firefox OS 1.4 because as our l10n team was told to finish the Firefox OS 1.4 UI translation and review as soon as possible.

So therefore, should regard this bug with more importance to be fixed before launching in Bangladesh. 
Topal, is it possible to fix it as soon as possible?

Comment 39

[Kadir Topal [:atopal]]

Safwan, this is already in the sprint, so we are planning on getting it done within the next few days.

Comment 40

[Ricky Rosario [:rrosario, :r1cky]]

Moving to the next sprint because we didn't get to it.

Comment 41

[Michael Cooper [:mythmon]]

PR: https://github.com/mozilla/kitsune/pull/2089/files

Comment 42

[Michael Cooper [:mythmon]]

I deployed this earlier.
Landed in: https://github.com/mozilla/kitsune/commit/73313a76c85ad01ad8843733472e106657830354

As well as adding support to our version detection algorithm for FxOS 1.4 and up, I fixed the bug that caused the problem. Now unrecognized FxOS version should be seen as simply unknown versions.