Closed Bug 737021 Opened 11 years ago Closed 11 years ago

Webm video is larger in play mode then when paused


(Firefox for Android Graveyard :: General, defect)

14 Branch
Not set


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

Tracking Status
firefox18 --- verified
blocking-fennec1.0 --- -
fennec 15+ ---


(Reporter: AdrianT, Assigned: wesj)


(Blocks 1 open bug)


(Whiteboard: [qa^])


(1 file)

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

Steps to reproduce:
1. Open Nightly.
2. Go to
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: --- → ?
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?
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
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.
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
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.
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.
I see similar problems with the opacity transitions on sometimes as well (seems to depend on the current zoom).
blocking-fennec1.0: + → soft
tracking-fennec: --- → 15+
blocking-fennec1.0: soft → -
Keywords: productwanted
This seems fixed by something.... Yay?
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.
Looking for how we regressed on aurora.
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.
Issue is present in Nightly on June 1st and fixed in June 2nd

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.
If I understand right, this is fixed in 15? Can we mark fixed?
Ever confirmed: false
Fixed for me on SGS GT-I9000, Fennec 16.0a1.
Closed: 11 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
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.