Webm video is larger in play mode then when paused

VERIFIED FIXED

Status

()

Firefox for Android
General
VERIFIED FIXED
6 years ago
2 years ago

People

(Reporter: AdrianT, Assigned: wesj)

Tracking

(Blocks: 1 bug)

14 Branch
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox18 verified, blocking-fennec1.0 -, fennec15+)

Details

(Whiteboard: [qa^])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 607162 [details]
Comparison play and pause mode

Fennec/14.0a1 2012-03-19
Device: HTC Desire (Android 2.2)

Steps to reproduce:
1. Open Nightly.
2. Go to http://people.mozilla.com/~nhirata/html_tp/elephants-dream.webm.
3. Make sure the video is in view.
4. Pause the video then tap play again.

Expected results:
Video size does not change.

Actual results:
Video is larger when in play mode then in pause. In pause the video is confined to the blue border but when played it extends outside of the border.
The issue may be related/caused by Bug 727236
This looks like the exact same issue filed in bug 736033 which is dependant on bug 727236.
Depends on: 727236
Seems related to those bugs, yes, but it's odd that it changes size on pause/resume. Can't see why that would be the case offhand, I don't know what, if anything, layout does during the pause/resume operations. I'll need to investigate this more.
blocking-fennec1.0: --- → ?

Comment 3

6 years ago
cpearce might know.
Dunno. The intrinsic size of the video will be 300x150 until the metadata is loaded, then it'll be set to the video's dimensions. We otherwise don't change the intrinsic size of video elements. Maybe it's a controls bug? Or an invalidation bug?
(Assignee)

Comment 5

6 years ago
We do not download metadata automatically in Fennec. Could be that? But once you start playing, repausing should not do anything, and I'm not sure how we're getting a poster frame without downloading something either.
Wes, can you test if downloading the meta data "fixes" it?
Assignee: nobody → wjohnston
(Assignee)

Comment 7

6 years ago
Nope. Metadata prefs have no affect.

The video controls are drawn in the same place whether the video is playing (large) or paused (normal size), meaning that layout isn't aware things are resized I assume? Makes me suspicious that we're using a special layer for video that's not aware of some resizing tricks?
Finding a regression range might help here.
Duplicate of this bug: 738258
(Reporter)

Comment 10

6 years ago
The issue appeared on the Nightly/14.0a1 from 2012-03-15 - the first Nightly build after the maple merge. This issue is not reproducible on the Nightly/14.0a1 from 2012-03-14

Tested using a Motorola Droid 2 running Android 2.3.3
I think this may be related to the android-specific code in CompositorParent - it finds the root-scrollable frame and applies the transform to the associated layer, but perhaps there are situations where this is the incorrect layer?

If you pinch zoom-out, does the video remain in the same position? I think the same problem might apply to bug #732119
(Reporter)

Comment 12

6 years ago
I can see a similar issue to the one in bug 732119 on a larger screen like from a Nexus S if I zoom under 1X level and hold for the page not to bounce back i see that the video does not change zoom level. The issues may describe the same behavior/have the same cause.

Updated

6 years ago
blocking-fennec1.0: ? → +
When the video is paused we're probably not using a layer to render the video, which is why that works.
When we're rendering video with a layer, we set a transform on its ImageLayer to scale and position the video. I guess that's interacting poorly with the Fennec compositor.
(Assignee)

Comment 15

6 years ago
I see similar problems with the opacity transitions on http://thewebrocks.com/demos/targetgallery/ sometimes as well (seems to depend on the current zoom).
blocking-fennec1.0: + → soft
Whiteboard: [qa^]
tracking-fennec: --- → 15+
blocking-fennec1.0: soft → -
Keywords: productwanted
(Assignee)

Comment 16

6 years ago
This seems fixed by something.... Yay?
(Reporter)

Comment 17

6 years ago
The issue _is not_ reproducible on Nightly 16.0a1 2012-06-17 and Aurora 15.0a2 2012-06-17 on HTC Desire running Android 2.2. However the html5 video controls are broken on Aurora (Bug 763457) but are correctly displayed on Nightly.

The issue _is_ still reproducible on Firefox Mobile Native 14 Beta 7 build 3.

Comment 18

6 years ago
Looking for how we regressed on aurora.
Keywords: productwanted → regressionwindow-wanted
(Reporter)

Comment 19

6 years ago
The issue was fixed in Aurora 15.0a2 2012-06-05 when Nighty passed to Aurora (the upgrade from 14 to 15). I will try to look for the build that fixed this in Nightly so it can be uplifted and then a regression range for when the issue first occurred as I think the fix is more important to be uplifted.
(Reporter)

Comment 20

6 years ago
Issue is present in Nightly on June 1st and fixed in June 2nd

Changelog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=73783bf75c4c&tochange=5199196b65ec
(Reporter)

Comment 21

6 years ago
The regression was introduced on Nightly with the maple merge in Nightly 2012-03-14 a888f210af4e. The issue was not reproducible on Nightly 2012-03-14 c71845b3b2a6. Please readd the regressionwindow-wanted for further build bisection on maple fort he regression if needed.
Keywords: regressionwindow-wanted
Duplicate of this bug: 767625
(Assignee)

Comment 23

6 years ago
If I understand right, this is fixed in 15? Can we mark fixed?
Status: NEW → UNCONFIRMED
Ever confirmed: false
Fixed for me on SGS GT-I9000, Fennec 16.0a1.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
This issue is no longer reproducible on the latest Nightly. Closing bug as verified fixed on:

Firefox 18.0a1 (2012-09-13)
Device: Galaxy Note
OS: Android 4.0.4
Status: RESOLVED → VERIFIED
status-firefox18: --- → verified

Updated

5 years ago
Duplicate of this bug: 755780
You need to log in before you can comment on or make changes to this bug.