Status

defect
P1
normal
RESOLVED FIXED
7 months ago
5 months ago

People

(Reporter: esawin, Assigned: jhlin)

Tracking

({regression})

51 Branch
All
Android
Dependency tree / graph

Firefox Tracking Flags

(geckoview64 unaffected, firefox63 unaffected, firefox64 unaffected, firefox65 disabled, firefox66 fixed)

Details

Reporter

Description

7 months ago
Video playback is broken in latest GVE builds. I see repeated error log entries including:

I Gecko   : [Parent 13723, Compositor] WARNING: failed to lock front buffer: file /home/esawin/dev/g/gfx/layers/composite/ImageHost.cpp, line 204
I suspect this is due to bug 1486659.
Depends on: 1486659
Assignee

Comment 2

7 months ago
The patch shouldn't affect usual video playback as long as nothing blits the texture in the child process. Probably some gfx behavior that I missed or misunderstood.
Reporter

Comment 3

7 months ago
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #1)
> I suspect this is due to bug 1486659.

I think it should block in this case.
I can also confirm rbarker's error log locally.
Blocks: 1486659
No longer depends on: 1486659
Reporter

Comment 4

7 months ago
Backing out bug 1486659 seems to fix video playback.
Assignee

Comment 5

7 months ago
Eugen, do you have reliable STR for this? I've been playing video on YT but so far only managed to reproduce the problem once.
Assignee: nobody → jolin
Flags: needinfo?(esawin)
Reporter

Comment 6

7 months ago
(In reply to John Lin [:jhlin][:jolin] from comment #5)
> Eugen, do you have reliable STR for this? I've been playing video on YT but
> so far only managed to reproduce the problem once.

Loading any videos on imgur.com or 9gag.com failed for me.

STR:
1. Open http://me73.com/media
2. Push play on the H.264/MP4 (Video) video

Expected: video plays.
Actual: I think it was resizing the surface but no video playback, it stayed white.
Flags: needinfo?(esawin)
P1 because this is a regression. This bug is temporarily disabled because regressing bug 1486659 was backed out.
Assignee

Comment 8

7 months ago
Finally reproduced it and found the cause: the texture handles in parent and child processes will be out of sync after child process recreation, and compositor will get the wrong (used) handle. To address this, I'll update the patches in bug 1486659 to make the texture in the child process uses the same handle as the original texture to avoid the situation.

Updated

6 months ago
Product: Firefox for Android → GeckoView

(In reply to John Lin [:jhlin][:jolin] from comment #8)

Finally reproduced it and found the cause: the texture handles in parent and
child processes will be out of sync after child process recreation, and
compositor will get the wrong (used) handle. To address this, I'll update
the patches in bug 1486659 to make the texture in the child process uses the
same handle as the original texture to avoid the situation.

John, is this bug still a problem? Or did your patches in bug 1486659 fix this issue?

Flags: needinfo?(jolin)
Assignee

Comment 10

5 months ago

So sorry for forgetting to update this bug. Yes, the patch in bug 1486659 fixed this issue.

Status: NEW → RESOLVED
Closed: 5 months ago
Flags: needinfo?(jolin)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.