Summary: | [BlackBerry] Conditionally enlarge HTML5 video controls in fullscreen mode | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Max Feil <mfeil> | ||||||||||||||||||||||||
Component: | WebKit BlackBerry | Assignee: | Max Feil <mfeil> | ||||||||||||||||||||||||
Status: | CLOSED FIXED | ||||||||||||||||||||||||||
Severity: | Normal | CC: | cmarcelo, dpranke, eric.carlson, eric, feature-media-reviews, jer.noble, jkjiang, jonathan.dong.webkit, kpiascik, macpherson, menard, philn, rakuco, rwlbuis, tkent, tonikitoo, webkit.review.bot | ||||||||||||||||||||||||
Priority: | P2 | ||||||||||||||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||||||||||||||
Hardware: | Other | ||||||||||||||||||||||||||
OS: | Other | ||||||||||||||||||||||||||
Bug Depends on: | 87817 | ||||||||||||||||||||||||||
Bug Blocks: | |||||||||||||||||||||||||||
Attachments: |
|
Description
Max Feil
2012-05-25 16:53:28 PDT
Created attachment 144172 [details]
Patch
Attachment 144172 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1
Source/WebCore/platform/blackberry/RenderThemeBlackBerry.cpp:26: Alphabetical sorting problem. [build/include_order] [4]
Source/WebCore/platform/blackberry/RenderThemeBlackBerry.cpp:156: One line control clauses should not use braces. [whitespace/braces] [4]
Source/WebCore/platform/blackberry/RenderThemeBlackBerry.cpp:760: A case label should not be indented, but line up with its switch statement. [whitespace/indent] [4]
Source/WebCore/platform/blackberry/RenderThemeBlackBerry.cpp:789: A case label should not be indented, but line up with its switch statement. [whitespace/indent] [4]
Source/WebCore/ChangeLog:31: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] [5]
Total errors found: 5 in 9 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 144172 [details] Patch Attachment 144172 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/12800634 Created attachment 144175 [details]
Patch
Even though this patch is not 100% complete, I would like to get an initial review. Mainly I would like to be sure that my approach of adding a new parameter to adjustSliderThumbSize() is acceptable. If so, I will update the patch with code changes for the other ports, and tests. Attachment 144175 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1
Source/WebCore/ChangeLog:31: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] [5]
Total errors found: 1 in 9 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 144175 [details] Patch Attachment 144175 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/12801616 Comment on attachment 144175 [details] Patch Attachment 144175 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/12808542 Comment on attachment 144175 [details] Patch Attachment 144175 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/12804644 Comment on attachment 144175 [details] Patch Attachment 144175 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/12804635 Comment on attachment 144175 [details] Patch Attachment 144175 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12794649 Comment on attachment 144175 [details] Patch Attachment 144175 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/12795686 Created attachment 144182 [details]
Patch
Attachment 144182 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1
Source/WebCore/ChangeLog:31: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] [5]
Total errors found: 1 in 34 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 144182 [details] Patch Attachment 144182 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/12800653 Comment on attachment 144182 [details] Patch Attachment 144182 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/12802614 Comment on attachment 144182 [details] Patch Attachment 144182 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/12794665 Created attachment 144184 [details]
Patch
Attachment 144184 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1
Source/WebCore/ChangeLog:31: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] [5]
Total errors found: 1 in 34 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 144184 [details] Patch Attachment 144184 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/12793650 Comment on attachment 144184 [details] Patch Attachment 144184 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/12807634 Comment on attachment 144184 [details] Patch Attachment 144184 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/12800660 Comment on attachment 144184 [details] Patch Attachment 144184 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/12804670 Comment on attachment 144184 [details] Patch Attachment 144184 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/12794669 Comment on attachment 144184 [details] Patch Attachment 144184 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12799733 Created attachment 144188 [details]
Patch
Attachment 144188 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1
Source/WebCore/ChangeLog:31: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] [5]
Total errors found: 1 in 34 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 144188 [details] Patch Attachment 144188 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/12802625 Created attachment 144191 [details]
Patch
Attachment 144191 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1
Source/WebCore/ChangeLog:31: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] [5]
Total errors found: 1 in 35 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 144191 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=144191&action=review I think the change to viewport should be of its own. I did not look at the rest deeply, but that would be enough for an r- ... leaving r? so other can walk-in and review. +Jacky and Konrad who last touched it. > Source/WebCore/platform/blackberry/RenderThemeBlackBerry.cpp:154 > + for (int i = 1; object && i <= 3; i++) why 3? > Source/WebKit/blackberry/Api/WebPage.cpp:3340 > IntSize WebPagePrivate::recomputeVirtualViewportFromViewportArguments() > { > static const ViewportArguments defaultViewportArguments; > - if (m_viewportArguments == defaultViewportArguments) > + if (m_viewportArguments == defaultViewportArguments) { > + m_page->setDeviceScaleFactor(1.0); > return IntSize(); > + } > Jacky, Konrad? > Source/WebKit/blackberry/Api/WebPage.cpp:3378 > void WebPagePrivate::dispatchViewportPropertiesDidChange(const ViewportArguments& arguments) > { > - static ViewportArguments defaultViewportArguments; > - if (arguments == defaultViewportArguments) > + if (arguments == m_viewportArguments) > return; Jacky, Konrad? Comment on attachment 144191 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=144191&action=review > Source/WebKit/blackberry/Api/WebPage.cpp:3337 > + m_page->setDeviceScaleFactor(1.0); I don't think we currently reset the deviceScaleFactor, so this is a good change r+ for this method from me. > Source/WebKit/blackberry/Api/WebPage.cpp:3377 > + if (arguments == m_viewportArguments) This change looks good to me too. I'm not sure why we check against default ags here since we don't really care about default, but rather if the new args are different from m_viewportArguments. (In reply to comment #32) > (From update of attachment 144191 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=144191&action=review > > > Source/WebKit/blackberry/Api/WebPage.cpp:3337 > > + m_page->setDeviceScaleFactor(1.0); > > I don't think we currently reset the deviceScaleFactor, so this is a good change r+ for this method from me. > > > Source/WebKit/blackberry/Api/WebPage.cpp:3377 > > + if (arguments == m_viewportArguments) > > This change looks good to me too. I'm not sure why we check against default ags here since we don't really care about default, but rather if the new args are different from m_viewportArguments. I agree with Antonio that the above changes could/should be in their own patch. Then you could make this bug depend on the other patch. (In reply to comment #31) > > Source/WebCore/platform/blackberry/RenderThemeBlackBerry.cpp:154 > > + for (int i = 1; object && i <= 3; i++) > > why 3? This comes from the nested node structure of the media controls. I did not change the functionality of this part of the code, just created a more efficient convenience function. Created attachment 144697 [details]
Patch
Attachment 144697 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1
Source/WebCore/ChangeLog:31: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] [5]
Total errors found: 1 in 33 files
If any of these errors are false positives, please file a bug against check-webkit-style.
I have separated the Source/WebKit/blackberry into its own bug and made this bug depend on it. I am still hoping for feedback on the addition of a new Element* parameter to RenderTheme::adjustSliderThumbSize(), as mentioned in Comment #0. If I don't hear anything I will assume that all are in agreement. And yes, I know I still need tests... Comment on attachment 144697 [details]
Patch
R- because of the style queue thing. Also once you do a new patch (I assume you are adding tests) can you add the PR number, if any?
Created attachment 145468 [details]
Patch
This is part of PR140677. Comment on attachment 145468 [details] Patch Attachment 145468 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12869889 New failing tests: platform/blackberry/media/video-controls-enlarged-fullscreen-nometa.html platform/blackberry/media/video-controls-enlarged-fullscreen-meta.html Created attachment 145472 [details]
Archive of layout-test-results from ec2-cr-linux-04
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-04 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
(In reply to comment #41) > (From update of attachment 145468 [details]) > Attachment 145468 [details] did not pass chromium-ews (chromium-xvfb): > Output: http://queues.webkit.org/results/12869889 > > New failing tests: > platform/blackberry/media/video-controls-enlarged-fullscreen-nometa.html > platform/blackberry/media/video-controls-enlarged-fullscreen-meta.html Why are other ports running BlackBerry platform specific tests? Am I missing something?? (In reply to comment #43) > (In reply to comment #41) > > (From update of attachment 145468 [details] [details]) > > Attachment 145468 [details] [details] did not pass chromium-ews (chromium-xvfb): > > Output: http://queues.webkit.org/results/12869889 > > > > New failing tests: > > platform/blackberry/media/video-controls-enlarged-fullscreen-nometa.html > > platform/blackberry/media/video-controls-enlarged-fullscreen-meta.html > > Why are other ports running BlackBerry platform specific tests? Am I missing something? Dirk, would you know? Comment on attachment 145468 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=145468&action=review The approach look sane to me, but I still have some questions/requests. does your patch fix the problem that HTML5 controls (with the new fullscreen API) are getting differently scaled according to the webpage scale? > Source/WebCore/platform/blackberry/RenderThemeBlackBerry.cpp:154 > + for (int i = 1; object && i <= 3; i++) please add a comment about these values. > Source/WebCore/platform/blackberry/RenderThemeBlackBerry.cpp:167 > + int fullScreenMultiplier = 1; > +#if ENABLE(FULLSCREEN_API) && ENABLE(VIDEO) > + if (element && element->document()->webkitIsFullScreen() && element->document()->webkitCurrentFullScreenElement() == toParentMediaElement(element)) { > + if (element->document()->page()->deviceScaleFactor() < scaleFactorThreshold) > + fullScreenMultiplier = fullScreenEnlargementFactor; > + } > +#endif webkit has a tendency of early return instead of nesting if checks. > Source/WebCore/platform/blackberry/RenderThemeBlackBerry.cpp:757 > + Length controlsHeight(mediaControlsHeight * fullScreenMultiplier, Fixed); > + Length timeWidth(mediaControlsHeight * 3 / 2 * fullScreenMultiplier, Fixed); > + Length volumeHeight(mediaControlsHeight * 4 * fullScreenMultiplier, Fixed); > + Length padding(mediaControlsHeight / 8 * fullScreenMultiplier, Fixed); > + int fontSize = mediaControlsHeight / 2 * fullScreenMultiplier; could you explain where these literals come from (3, 2, 4, 8)? > Source/WebCore/platform/blackberry/RenderThemeBlackBerry.cpp:787 > + Length volumeHeight(mediaControlsHeight * 4 * fullScreenMultiplier, Fixed); what is 4 herE? (In reply to comment #45) > please add a comment about these values. > could you explain where these literals come from (3, 2, 4, 8)? > what is 4 herE? The items you are asking me to comment are all from pre-existing code that I did not write. I will gladly add comments, but I don't think this should hold up landing of my patch. (In reply to comment #43) > (In reply to comment #41) > > (From update of attachment 145468 [details] [details]) > > Attachment 145468 [details] [details] did not pass chromium-ews (chromium-xvfb): > > Output: http://queues.webkit.org/results/12869889 > > > > New failing tests: > > platform/blackberry/media/video-controls-enlarged-fullscreen-nometa.html > > platform/blackberry/media/video-controls-enlarged-fullscreen-meta.html > > Why are other ports running BlackBerry platform specific tests? Am I missing something?? That does seem strange, I also thought having it in platform/port made it visible for the port only. Maybe we need to skip it for chromium these days? (In reply to comment #47) > That does seem strange, I also thought having it in platform/port made it visible for the port only. Maybe we need to skip it for chromium these days? Of the 7 ports in the EWS, only cr-linux runs tests. The others are build-only. I'm not sure why this is, but it does mean we have to assume all ports will attempt to run my new BlackBerry-only tests (and fail). I will investigate what is being done for the other ports and implement platform/blackberry the same way Created attachment 145675 [details]
Patch
I have resolved the test failure the same way the existing platform/blackberry test was being skipped. I also believe I have addressed all comments made about this patch so far, and look forward to a swift conclusion :) Comment on attachment 145675 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=145675&action=review r=me one minor request bellow to address before it lands.. Test could get improved but I think it is ok. > Source/WebCore/platform/blackberry/RenderThemeBlackBerry.cpp:154 > + // The RenderSlider is 3 parent levels about the slider thumb nit: misses a . at the end (coding style). I would add an ASSERT here to indicate what your RenderObject is/will be. Created attachment 145810 [details]
Patch
Comment on attachment 145810 [details] Patch Clearing flags on attachment: 145810 Committed r119547: <http://trac.webkit.org/changeset/119547> All reviewed patches have been landed. Closing bug. Closing bug for patch that landed a long time ago. |