video_MultiplePlayback failed: Tab2: Running YouTube in Flash mode |
||||||
Issue description
File "/usr/local/autotest/tests/video_MultiplePlayback/video_MultiplePlayback.py", line 74, in run_video_tests
raise error.TestFail('Tab2: Running YouTube in Flash mode.')
since 3 days ago (around 9633.0.0).
Feel free to assign back to me if this is problem in chrome, not problem of test itself.
,
Jul 11 2017
,
Jul 11 2017
,
Jul 11 2017
,
Jul 11 2017
,
Jul 11 2017
kcwu@, it seems that the Flash player plugin is getting loaded with the browser. Even though the videos seem to be playing in the HTML5 player. The test currently tries to ascertain that the HTML5 player is being used by making sure that a plugin of type ppapi is not loaded, but in this case it is. Do you know if that is the new design? I can find another way to check for HTML5 player, but want to first check that loading Flash even without Flash content is not a bug.
,
Jul 11 2017
,
Jul 11 2017
I opened up the task manager and observed it for a short while, the task "Plugin broker: Shockwave flash" is started but sits at 0 CPU for about a minute and then goes away. Is that by design?
,
Jul 11 2017
Chrome started the broker for a bit. It probably shouldn't do that, but has done so forever. Flash didn't start. ps -ef | grep "type=ppapi" /opt/google/chrome/chrome --type=ppapi-broker - Notice not every ppapi process is Flash. Take a look at verify_flash_process() in desktopui_FlashSanityCheck.py. It does a slightly better check, but could protect against the broker or other ppapi processes better.
,
Jul 13 2017
Thanks Ilja!
I'm going to change the condition to be this:
broker_proc = utils.get_process_list('chrome', '--type=ppapi-broker')
maybe_broker_proc = utils.get_process_list('chrome', '--type=ppapi')
if len(maybe_broker_proc) > len(broker_proc):
raise error.TestFail('Tab2: Running YouTube in Flash mode.')
This would be a false pass in the narrow case that the broker process gives way to the actual Flash plugin in the span of time between the two pgrep calls, but I think that should be an ok risk. Will send out the CR, let me know there if there's a better way to do it.
,
Jul 13 2017
There are other non-Flash type=ppapi processes and other corner cases (like zygote). You need to move verify_flash_process() into a utils.py file and then call it from desktopui_FlashSanityCheck and from video_MultiplePlayback. https://cs.corp.google.com/chromeos_public/src/third_party/autotest/files/client/site_tests/desktopui_FlashSanityCheck/desktopui_FlashSanityCheck.py?q=verify_flash_process+package:%5Echromeos_public$&l=152
,
Jul 15 2017
I see that the verify_flash_process method does some deeper checks to make sure Flash *is* running, like waiting for a few seconds to ensure the process is still around, checking load paths, checking log files and ensuring the browser did not crash. Question is, I'm wondering if negating those checks to make sure Flash isn't loaded would make sense or not. Also, if making sure that Flash doesn't get loaded for HTML5 video playback is important then I think it would be better to make that a dedicated test for clarity. So, I think what I'm proposing is this: 1. I find a way to make sure that HTML5 playback is happening for the video on the current tab and refactor this test to only do that check. 2. Create a dedicated test to make sure Flash doesn't get loaded for non-Flash video content and refactor the related files. Does that sound good? |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by avkodipelli@chromium.org
, Jun 16 2017