Closed Bug 824118 Opened 7 years ago Closed 7 years ago

Android graphics block request: STAGEFRIGHT feature on the following Hardware field values: antares, endeavoru, harmony, picasso, picasso_e, ventana

Categories

(Toolkit :: Blocklist Policy Requests, defect)

defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: bjacob, Assigned: bjacob)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: qawanted, Whiteboard: [gfx])

Attachments

(1 file)

Please add 6 Android blocklist entries, one for each of the following values of the Hardware field:

OS: Android
OS version: all
Feature: STAGEFRIGHT
Manufacturer: all 6 following values:
  antares
  endeavoru
  harmony
  picasso
  picasso_e
  ventana

Feature status: BLOCKED_DEVICE

Reasons: major crashiness when decoding H264 video. See bug 802827 comment 35.
Argh! In comment 0 I made a *very important typo*:

Instead of 'Manufacturer' please read 'Hardware'.

The field to check for those 6 values is the Hardware field.

Thanks!
Assignee: nobody → jorge
QA Contact: aaron.train
(In reply to Benoit Jacob [:bjacob] (On vacation, back on Jan. 7th) from comment #1)
> Instead of 'Manufacturer' please read 'Hardware'.

Is this the device field in the block?

The blocks are staged with ids: 243, 245, 247, 249, 251 and 253.
Keywords: qawanted
'Hardware' is an Android-specific field.

The XML should look like:

   <hardware>picasso</hardware>

(Source: widget/xpwidgets/GfxInfoBase.cpp)
Is there a bug on file to support this in the blocklist administration interface?
I haven't filed one so I suppose that there is none (didn't know about that / don't know where to file / am on vacation / sorry / thanks! / :-) )
Is it possible to implement it now that bug 824721 is fixed?
Yes. I just changed the staged blocklist entries to use the Hardware value. Please test now.
Hey, I completely lost track of this bug. Are the requested blocklist entries in production?
(In reply to Benoit Jacob [:bjacob] from comment #8)
> Hey, I completely lost track of this bug. Are the requested blocklist
> entries in production?

No, the blocks are staged and I need confirmation that they are working correctly.
Ah, great, thanks.
What are the device names for the models with these issues?
Hm, your best bet is to extract that information from our crash reports. Here's a bash command to extract from the reports since Jan 20 what 'antares' corresponds to (filtering only results with at least 10 crash reports over that period):

$ zcat 2013012*-pub-crashdata.csv.gz | grep 'Hardware: antares' | sed 's/^.*\(Model[^|]*\)|.*$/\1/g' | sort | uniq -c | sort -rn | grep "^\ *[0-9][0-9]"
   1077 Model: AT100, Product: tostab03, Manufacturer: TOSHIBA, Hardware: antares' 
    114 Model: AT100, Product: unknown, Manufacturer: TOSHIBA, Hardware: antares' 

-> so 'antares' is the Toshiba AT100.

And so on:

$ zcat 2013012*-pub-crashdata.csv.gz | grep 'Hardware: endeavoru' | sed 's/^.*\(Model[^|]*\)|.*$/\1/g' | sort | uniq -c | sort -rn | grep "^\ *[0-9][0-9]"
   3408 Model: HTC One X, Product: endeavoru, Manufacturer: HTC, Hardware: endeavoru' 
     42 Model: HTC One X, Product: tg_endeavoru, Manufacturer: unknown, Hardware: endeavoru' 
     24 Model: EndeavorU, Product: endeavoru, Manufacturer: HTC, Hardware: endeavoru' 

-> so 'endeavoru' is the HTC One X

$ zcat 2013012*-pub-crashdata.csv.gz | grep 'Hardware: harmony' | sed 's/^.*\(Model[^|]*\)|.*$/\1/g' | sort | uniq -c | sort -rn | grep "^\ *[0-9][0-9]"
     85 Model: VegaBean Beta 6, Product: full_shuttle, Manufacturer: NVidia, Hardware: harmony' 
     33 Model: VegaBean Beta 3-1, Product: full_shuttle, Manufacturer: NVidia, Hardware: harmony' 
     29 Model: Malata SMBA1002, Product: full_smba1002, Manufacturer: Malata, Hardware: harmony' 
     21 Model: Notion Ink ADAM, Product: cm_adam_3g, Manufacturer: unknown, Hardware: harmony' 
     16 Model: TeamDRH ICS for GTablet, Product: tervigon, Manufacturer: Malata, Hardware: harmony' 
     16 Model: Malata SMBA1002, Product: drh_smba1002, Manufacturer: unknown, Hardware: harmony' 
     15 Model: ViewPad 10S, Product: ViewPad 10S, Manufacturer: ViewSonic, Hardware: harmony' 
     15 Model: VegaBean Beta 5, Product: full_shuttle, Manufacturer: NVidia, Hardware: harmony' 
     15 Model: tervigon, Product: tervigon, Manufacturer: Motorola, Hardware: harmony' 
     13 Model: VegaBean Beta 3, Product: full_shuttle, Manufacturer: NVidia, Hardware: harmony' 
     11 Model: SN10T1, Product: tervigon, Manufacturer: Malata, Hardware: harmony' 

-> so... ouch, 'harmony' is a long tail of obscure devices, the most popular of which only gave 85 crash reports over a week....

$ zcat 2013012*-pub-crashdata.csv.gz | grep 'Hardware: picasso' | sed 's/^.*\(Model[^|]*\)|.*$/\1/g' | sort | uniq -c | sort -rn | grep "^\ *[0-9][0-9]"
    859 Model: A500, Product: a500_ww_gen1, Manufacturer: Acer, Hardware: picasso' 
    632 Model: A700, Product: a700_emea_de, Manufacturer: Acer, Hardware: picasso_mf' 
    491 Model: A500, Product: a500_pa_cus1, Manufacturer: Acer, Hardware: picasso' 
    382 Model: A500, Product: picasso, Manufacturer: Acer, Hardware: picasso' 
    363 Model: A510, Product: a510_emea_de, Manufacturer: Acer, Hardware: picasso_m' 
    358 Model: A200, Product: a200_pa_cus1, Manufacturer: Acer, Hardware: picasso_e' 
    312 Model: A701, Product: a701_ww_gen1, Manufacturer: Acer, Hardware: picasso_mf' 
    312 Model: A210, Product: a210_emea_de, Manufacturer: Acer, Hardware: picasso_e2' 
    277 Model: A210, Product: a210_emea_fr, Manufacturer: Acer, Hardware: picasso_e2' 
 (*** TRIMMED --- GETTING A VERY LONG TAIL ***)

-> so 'picasso' and 'picasso_e' are part of a large family of Acer tablets; 'picasso' is the A500 and picasso_e is the A200.

$ zcat 2013012*-pub-crashdata.csv.gz | grep 'Hardware: ventana' | sed 's/^.*\(Model[^|]*\)|.*$/\1/g' | sort | uniq -c | sort -rn | grep "^\ *[0-9][0-9]"
   1038 Model: Transformer TF101, Product: WW_epad, Manufacturer: asus, Hardware: ventana' 
    994 Model: Transformer TF101, Product: US_epad, Manufacturer: asus, Hardware: ventana' 
    329 Model: Transformer, Product: US_epad, Manufacturer: asus, Hardware: ventana' 
    326 Model: MD_LIFETAB_P9516, Product: MD_LIFETAB_P9516, Manufacturer: MEDION, Hardware: ventana' 
    237 Model: Transformer TF101G, Product: WW_epad, Manufacturer: asus, Hardware: ventana' 
    186 Model: LIFETAB_P9514, Product: LIFETAB_P9514_de, Manufacturer: MEDION, Hardware: ventana' 
    179 Model: ThinkPad Tablet, Product: ThinkPadTablet, Manufacturer: LENOVO, Hardware: ventana' 
    137 Model: Slider SL101, Product: WW_epad, Manufacturer: asus, Hardware: ventana' 
 (*** TRIMMED --- GETTING A VERY LONG TAIL ***)

-> so 'ventana' hardware is used in a wide range of products, the most popular of which are various Asus Transformer's, especially the TF101.
(In reply to Benoit Jacob [:bjacob] from comment #0)
> OS version: all
Is that allowed? I though it was the API version and maybe Android version recently.
Flags: needinfo?(bjacob)
(In reply to Scoobidiver from comment #13)
> (In reply to Benoit Jacob [:bjacob] from comment #0)
> > OS version: all
> Is that allowed? I though it was the API version and maybe Android version
> recently.

"all" is achieved by just *not* putting a OS version XML tag ;-)

I should not have mentioned it, as it was just confusing, I guess.
Flags: needinfo?(bjacob)
I suggest going ahead with these blocklist entries without waiting for QA. This is a topcrasher. In the worst case, this will not resolve the crashes, but this won't make them worse. We'll know from crash-stats.
Done. Block IDs: 264, 266, 268, 270, 272, 274.

Do you want the same for bug 836203?
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Thanks, and yes, please do 836203 too --- there too, we will be able to QA it from crash-stats after the fact.
Thanks. It's important to keep that wiki page up to date.
(In reply to Benoit Jacob [:bjacob] from comment #19)
> It's important to keep that wiki page up to date.
You can rebuild one at any time with the blocklist.xml file in any profile.
That's a good tip for the downloadable blacklist, although already it requires some knowledge about what the XML fields exactly mean. But there is also the built-in blocklist. All in all, I feel that it's important to keep this wiki page up to date because reconstructing it from scratch would be quite a bit of work.
There is also the back-references to bug numbers --- we don't have that information in the XML, and it's very important to keep a record of it. (Hint, that would be a very useful addition).
We have a 10-fold increase of aborts with "OpenGL-accelerated layers are a hard requirement on this platform [...]" (mostly startup) since yesterday, see bug 783196, and that's across all branches, including release, could this blocklist be connected to that?
Depends on: 838603
I filed bug 838603 on the problem mentioned in comment #23 - I suspect we blocked those devices from using OpenGL layers (which makes us not launch at all any more) instead of just blocking libstagefright usage. How well did we QA this blocklist change?
(In reply to Benoit Jacob [:bjacob] from comment #15)
> I suggest going ahead with these blocklist entries without waiting for QA.
> This is a topcrasher. In the worst case, this will not resolve the crashes,
> but this won't make them worse. We'll know from crash-stats.

Fun that you said that, as it looks this replaced it with a way, way worse topcrasher. There's a reason we QA things. :-/
These blocks have been pulled back due to bug 808378.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Jorge Villalobos [:jorgev] from comment #26)
> These blocks have been pulled back due to bug 808378.

I meant bug 838603, of course.
I have to say I feel sorry now for asking for this not to wait for QA; but how in the world did this STAGEFRIGHT blocklist entry end up blocking layers?
In #mobile Kairo says that through sifting through some of the crash reports the hardware ID's mentioned here are not the top reported; so now this is all the more interesting.
Yes, looking through the raw JSON of a number of those crashes/aborts, it's not restricted to the hardware we have blocked, so it might be caused by something different. That said, we don't have a better clue yet, as it must be something that affects all channels the same, and I somewhat doubt that a lot of vendors would ship a firmware update on the same day that breaks us (esp. as there's Android versions at least between 2.3 and 4.0 affected, probably more).
Jorge: for debugging value, could you post here the XML that was used for these blocklist rules?
Here's the fragment from blocklist.xml that corresponds to the Android blocks. I just picked it up from blocklist.xml in my main profile.
Thanks. This looks good; I can't understand how this can have the observed consequences.
Depends on: 838845
Are we blocked on the redesign proposed in bug 838845, or are we blocked on making a version-specific blocklist addition to avoid bug 838845?
Over to Benoit, I don't know what should happen here anymore.
Assignee: jorge → bjacob
Yeah it's confusing and I forgot about this bug :-)

So the present blocklist entries use a new blocklist field, "hardware", which is only present in recent versions of Gecko. That's why they trigger the terrible bug that we discussed earlier.

So no, we shouldn't try to land this on the downloadable blacklist before the redesign being discussed in bug 838845, which has not been prioritized at this point (discussion about prioritization is best had directly with Milan, not me).

So for a short-term fix, we want to implement this in the built-in blacklist code, not the downloadable blacklist.

Filed bug 862523 for that. Let's close this bug now.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → WONTFIX
(In reply to Benoit Jacob [:bjacob] from comment #36)
> So no, we shouldn't try to land this on the downloadable blacklist before
> the redesign being discussed in bug 838845, which has not been prioritized
> at this point (discussion about prioritization is best had directly with
> Milan, not me).


Can't we change the server side to offer up per-version blocklists?
The server side just serves generic XML, the problem isn't there.

The problem is on the Firefox side, which receives the XML and doesn't look for a "firefox version" field in the XML. If we just kept the current blocklist system and added such a field, that would do nothing for the millions of users of outdated Firefox versions which would still get the same XML and not look for that field. So we have to also change our blocklist format to something incompatible enough that old firefoxen will not try to interprete the new blocklist entries.
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.