Closed Bug 1349208 Opened 4 years ago Closed 3 years ago
Outdated and now blocklisted flash plugin cause failures like Intermittent embed-represent-nothing-04
.html | /html/semantics/embedded-content/the-embed-element/embed-represent-nothing-04 .html d7f162e30cf91afbf48f49550744dec142eadfe4
59 bytes, text/x-review-board-request
james this is failing a lot on beta, do you know know whats going on here ?
The failing reftest shows a "This plugin is vunerable and should be updated" widget rather than an empty space. So I guess that's the problem. IDK what the right solution is (disabling the check? Updating the plugn version?).
do you know what the plugin is ? i have not seen a screenshot link, so a link to this would also be helpful to pass it to releng then :)
talked to james on irc and the plugin here in question is the flash plugin - so seems we need to fix settings of that image. moving to taskcluster
Component: web-platform-tests → Docker Images
Product: Testing → Taskcluster
Version: Version 3 → unspecified
moving to blocker since this affects the tier -1 tests
Severity: normal → blocker
garndt: wcosta: seems we need to update the image somehow (or disable flash completly)
also closing beta tree now for this failure
Summary: Intermittent /html/semantics/embedded-content/the-embed-element/embed-represent-nothing-04.html | /html/semantics/embedded-content/the-embed-element/embed-represent-nothing-04.html d7f162e30cf91afbf48f49550744dec142eadfe4 → Outdated and now blocklisted flash plugin cause failures like Intermittent embed-represent-nothing-04.html | /html/semantics/embedded-content/the-embed-element/embed-represent-nothing-04.html d7f162e30cf91afbf48f49550744dec142eadfe4
per discussion on irc, in order to reopen the trees i backed the blocklist update out in beta: https://hg.mozilla.org/releases/mozilla-beta/rev/4a0aabf1af708c0caf38c02dd0e877ab35734183 aurora: https://hg.mozilla.org/releases/mozilla-aurora/rev/e538aea0bf58f3a62381dcc62a41e94d11f20924 m-c : https://hg.mozilla.org/mozilla-central/rev/9fb5e850ab7ab0b2b90640c604f66038407b411d
This appears to only affect 16.04. This is an in-tree fix, so should probably be handled by one of the folks responsible for the test images. Joel's network connection isn't good today, though, so I'll see if I can help. I'm working on downloading the docker image to see why flash is installed.
Assignee: nobody → dustin
root@fbff8e62cc00:/# dpkg -S /usr/lib/flashplugin-installer/libflashplayer.so dpkg-query: no path found matching pattern /usr/lib/flashplugin-installer/libflashplayer.so on a base 16.04 docker image.. so .. where is this coming from?
..even enabling multiverse, that's still the case. And I can't download the task docker image due to bug 1349261 and bug 1347582. And I can't get a loaner due to the expired taskcluster-worker.net certificate.
root@8878862accae:~# dpkg -S /usr/lib/flashplugin-installer/libflashplayer.so dpkg-query: no path found matching pattern /usr/lib/flashplugin-installer/libflashplayer.so root@8878862accae:~# file /usr/lib/flashplugin-installer/libflashplayer.so /usr/lib/flashplugin-installer/libflashplayer.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=347feb5ef0183c7cb3fd807ae84f66b800bb75af, stripped >> baffled look <<
root@8878862accae:~# ls -alt /usr/lib/flashplugin-installer/ total 17884 drwxr-xr-x 156 root root 4096 Mar 8 14:56 .. drwxr-xr-x 2 root root 4096 Mar 8 14:53 . -rw-r--r-- 1 root root 18275072 Mar 8 14:53 libflashplayer.so -rwxr-xr-x 1 root root 792 Feb 15 20:24 install_plugin root@8878862accae:~# ls -alt /usr/lib/flashplugin-installer/install_plugin -rwxr-xr-x 1 root root 792 Feb 15 20:24 /usr/lib/flashplugin-installer/install_plugin root@8878862accae:~# dpkg -S /usr/lib/flashplugin-installer/install_plugin flashplugin-installer: /usr/lib/flashplugin-installer/install_plugin so the installer gets installed by by the `flashplugin-installer` package, and that then creates the installer itself. Yuck. root@8878862accae:~# apt-cache rdepends --installed flashplugin-installer flashplugin-installer Reverse Depends: ubuntu-restricted-addons root@8878862accae:~# apt-cache rdepends --installed ubuntu-restricted-addons ubuntu-restricted-addons Reverse Depends: ubuntu-restricted-extras root@8878862accae:~# apt-cache rdepends --installed ubuntu-restricted-extras ubuntu-restricted-extras Reverse Depends: And looking in dpkg.log: 2017-03-08 14:53:40 install ubuntu-restricted-extras:amd64 <none> 65 But ubuntu-restricted-extras is not in the list of things we install in the image.. >> baffled look <<
Ah (I was looking in the ubuntu1204 file, oops): hg blame gives: jmaher: # for mp4 codec (used in MSE tests) jmaher: apt-get -q -y -f install ubuntu-restricted-extras
So I suspect the fix here is to install exactly the extra we need for the mp4 codec, but in the interim I'll make a review req with a patch that just rm -f's libflashplugin.so. That should let us keep running without the plugin installed while we figure it out. Joel can redirect that figuring-out.
Comment on attachment 8849639 [details] Bug 1349208: temporary fix to get flashplayer out of the 16.04 image while we find a better fix; https://reviewboard.mozilla.org/r/122430/#review124570 I would like to ensure this works on try- who knows what tests depend on flash being installed!
Attachment #8849639 - Flags: review?(jmaher) → review+
I'm not good at diagnosing oranges, but I don't see anything screaming "where did flash player go!?!" in the try results so far.
Pushed by email@example.com: https://hg.mozilla.org/mozilla-central/rev/fd40abc21673 temporary fix to get flashplayer out of the 16.04 image while we find a better fix; r=jmaher, a=testers-only https://hg.mozilla.org/mozilla-central/rev/201231223cd4 Adjust web-platform-tests expectations to reflect not having Flash installed on 64-bit Ubuntu 16.04 just like we don't have it installed anywhere else, a=test-only
Based on some irc comments from last night, wpt apparently *do* depend on having Flash installed. So my patch wouldn't fix this -- it would just cause other tests to fail. 22:43:17 <@dustin> I'd say the right fix is to temporariliy hide/disable the tests that require flash, since we never intentionally installed flash 22:43:45 <@dustin> and then re-enable them when either (a) we decide to install flash, and disable the flash version check 22:43:51 <@dustin> or (b) we make the tests not require flash all of that is pretty far outside my expertise, so I'll leave it to those more expert.
That's not exactly right: three wpt tests depend on having Flash installed, so the test expectations for those three tests were already correctly set to expect NOTRUN or FAIL on every platform except 16.04, because we do not have Flash installed and do not want to have Flash installed in our test farm. So the combination of your patch removing Flash on 16.04 and my patch adjusting the expectations so we weren't expecting to run those three tests on 16.04 *did* fix it, correctly and permanently. The only thing which remains for this bug is finding a prettier way of not having Flash installed on 16.04, because rewriting the tests is out of scope for this bug tracker, they are owned by https://github.com/w3c/web-platform-tests, and deciding to have Flash installed on the testers on every version of every OS and keep it updated so we don't block our own version of it just so those three third-party tests can run is out of scope for sensible beings.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
Removing leave-open keyword from resolved bugs, per :sylvestre.
You need to log in before you can comment on or make changes to this bug.