Created attachment 285557 [details] screen shot of webkit video player, audio menu shows two options: "English" and "English" Summary: Audio Description tracks are not labeled correctly, causing user confusion Steps To Reproduce: 1. Load https://www.apple.com/media/us/iphone-6s/2016/af22bd64-5646-43f6-8b97-6085158f0cd7/tv-spots/shot-by-marc/iphone6s-shot-by-marc-cc-us-20160720_r848-9dwc.mov 2. Open the Audio menu. Results: See screen shot. The two tracks are both listed as simply "English." Expected: The second one should be "English [AD]" or "English w/ Audio Descriptions' Notes: Audio Descriptions are to blind users as captions are to deaf users. There is a media characteristic tag "public.accessibility.describes-video" on this audio track that identifies it as this type.
<rdar://problem/27742208>
Created attachment 285740 [details] Proposed patch.
Comment on attachment 285740 [details] Proposed patch. Attachment 285740 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/1847400 New failing tests: media/video-controls-captions-trackmenu-hide-on-click.html media/video-controls-captions-trackmenu-localized.html media/video-controls-captions-trackmenu-sorted.html media/video-controls-captions-trackmenu.html
Created attachment 285747 [details] Archive of layout-test-results from ews125 for ios-simulator-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews125 Port: ios-simulator-elcapitan-wk2 Platform: Mac OS X 10.11.5
Created attachment 285754 [details] Proposed patch.
Comment on attachment 285754 [details] Proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=285754&action=review > Source/WebCore/page/CaptionUserPreferencesMediaAF.cpp:660 > + return audioDescriptionTrackSuffixText(displayName.toString()); Since having a description track is a special case, I would have expected the if statement above to check whether we have one and return the suffix text in that case and let the default be the general case. > LayoutTests/http/tests/media/hls/hls-accessiblity-describes-video-menu.html:47 > + window.setTimeout(runTestsWithVisibleMenu, 100); Usage of setTimeout is typically a warning to me. What is the 100ms delay for here? Are we waiting on some layout due to some async event being dispatched? Could we use nested rAF calls to determine this has happened?
<rdar://problem/24705228>
Created attachment 286369 [details] Patch for landing.
Comment on attachment 286369 [details] Patch for landing. Clearing flags on attachment: 286369 Committed r204601: <http://trac.webkit.org/changeset/204601>
All reviewed patches have been landed. Closing bug.