737021 - Webm video is larger in play mode then when paused

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Adrian Tamas (:AdrianT)]

Attachment: 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

Comment 1

[Aaron Train [:aaronmt]]

This looks like the exact same issue filed in bug 736033 which is dependant on bug 727236.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 3

[JP Rosevear [:jpr]]

cpearce might know.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

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?

Comment 5

[Wesley Johnston (:wesj)]

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.

Comment 6

[Brad Lassey [:blassey] (use needinfo?)]

Wes, can you test if downloading the meta data "fixes" it?

Comment 7

[Wesley Johnston (:wesj)]

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?

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

Finding a regression range might help here.

Comment 10

[Adrian Tamas (:AdrianT)]

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

Comment 11

[Chris Lord [:cwiiis]]

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

Comment 12

[Adrian Tamas (:AdrianT)]

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.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

When the video is paused we're probably not using a layer to render the video, which is why that works.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 15

[Wesley Johnston (:wesj)]

I see similar problems with the opacity transitions on http://thewebrocks.com/demos/targetgallery/ sometimes as well (seems to depend on the current zoom).

Comment 16

[Wesley Johnston (:wesj)]

This seems fixed by something.... Yay?

Comment 17

[Adrian Tamas (:AdrianT)]

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

[JP Rosevear [:jpr]]

Looking for how we regressed on aurora.

Comment 19

[Adrian Tamas (:AdrianT)]

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.

Comment 20

[Adrian Tamas (:AdrianT)]

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

Comment 21

[Adrian Tamas (:AdrianT)]

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.

Comment 23

[Wesley Johnston (:wesj)]

If I understand right, this is fixed in 15? Can we mark fixed?

Comment 24

[Chris Pearce [:cpearce (Not reading bugmail)]]

Fixed for me on SGS GT-I9000, Fennec 16.0a1.

Comment 25

[Cristian Nicolae (:xti)]

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