Closed Bug 1077157 Opened 10 years ago Closed 8 years ago

Youtube video controls missing >96 DPI setting 125% (OR Zoom out with default DPI) on win7 x64

Categories

(Core :: Graphics, defect)

37 Branch
x86_64
Windows 7
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
Tracking Status
platform-rel --- ?
firefox34 --- unaffected
firefox35 - affected
firefox36 --- fixed

People

(Reporter: jmjjeffery, Assigned: bas.schouten)

References

Details

(Keywords: regression, Whiteboard: [platform-rel-Youtube])

Attachments

(1 file)

86.41 KB, application/x-zip-compressed
Details
With screen resolution setting of 125% in Win7 x64, i.e. > 96DPI the video controls are only partially visible.  The controls work if you hover the mouse over where they 'should be' and wait for the cursor to change to a 'hand'.

Bad in cset: af6c928893c0
Good cset:   f771fd927304

I suspect it is caused by landing of:
https://bugzilla.mozilla.org/show_bug.cgi?id=902952  

That bug seemingly fixed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1075467 which was marked as a dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=1075616 

I am wondering if bug 1075616 will fix this bug or whether there are yet more dependencies waiting to land.

Requesting regression-window wanted to see if bug 902952 is indeed the cause.
In local build,
Last Good: 1dbdf3202f04
First Bad: d954ed24e795

Triggered by:
 d954ed24e795	Bas Schouten — Bug 902952 - Part 2: Use Direct2D 1.1 where available. r=jrmuizel
More testing, this appears to happen mainly on Youtube with HTML5 vids, Flash based videos have the controls displayed.  Only show missing on HTML5.
I updated to latest build today and I have same problem. My DPI setting is set to 113 % and youtube controls doesn't show up on html5 videos. I remember something similar was happening with vertical scrollbar but got fixed 1 week ago.(https://bugzilla.mozilla.org/show_bug.cgi?id=1060675)
Regression window with force enable Direct2D1.1
user_pref("gfx.canvas.azure.backends", "direct2d1.1,direct2d,skia,cairo");
user_pref("gfx.content.azure.backends", "direct2d1.1,direct2d,cairo");
user_pref("gfx.direct2d.use1_1", true);

Inlocal build
Last Good: 20e97c8496e4
First Bad: 7b9201731195

Triggered by
7b9201731195	Matt Woodrow — Bug 1046550 - Part 3: Use Direct2D 1.1 when preffed on. r=bas
Blocks: 1046550
(In reply to Alice0775 White from comment #4)
> Regression window with force enable Direct2D1.1
> user_pref("gfx.canvas.azure.backends", "direct2d1.1,direct2d,skia,cairo");
> user_pref("gfx.content.azure.backends", "direct2d1.1,direct2d,cairo");
> user_pref("gfx.direct2d.use1_1", true);
> 
> Inlocal build
> Last Good: 20e97c8496e4
> First Bad: 7b9201731195
> 
> Triggered by
> 7b9201731195	Matt Woodrow — Bug 1046550 - Part 3: Use Direct2D 1.1 when
> preffed on. r=bas

I have those settings on by default and stil same problem.
Also reproducing on Latest Nightly (build ID: 20141019030207) using a Microsoft Surface Pro 2 device running Windows 8.1 64-bit.
I've also been having this issue on nightly and 64-bit Windows 7.  My scaling is set to 100%, though.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
> Apparently this build fixes the problem:
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> com-de32e9b7ea2a/try-win32/

Did this land into m-c ?  

I rechecked this morning and I'm not seeing the problem anymore...
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #9)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
> > Apparently this build fixes the problem:
> > 
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> > com-de32e9b7ea2a/try-win32/
> 
> Did this land into m-c ?  
> 
> I rechecked this morning and I'm not seeing the problem anymore...

Nevermind - forgot I had Ctrl - (minus) the page to get to show...  Still an issue
(In reply to andrewseul from comment #5)
> (In reply to Alice0775 White from comment #4)
> > Regression window with force enable Direct2D1.1
> > user_pref("gfx.canvas.azure.backends", "direct2d1.1,direct2d,skia,cairo");
> > user_pref("gfx.content.azure.backends", "direct2d1.1,direct2d,cairo");
> > user_pref("gfx.direct2d.use1_1", true);
> > 
> > Inlocal build
> > Last Good: 20e97c8496e4
> > First Bad: 7b9201731195
> > 
> > Triggered by
> > 7b9201731195	Matt Woodrow — Bug 1046550 - Part 3: Use Direct2D 1.1 when
> > preffed on. r=bas
> 
> I have those settings on by default and stil same problem.

These setting are purpose of finding regression range.
Summary: Youtube video controls missing >96 DPI setting 125% on win7 x64 → Youtube video controls missing >96 DPI setting 125% (OR Zoom out with default DPI) on win7 x64
Attached file reduced html
Steps To Reproduce:
1. set 100% display size
2. Open reduced html
3. Zoom-out several time
    OR
     Zoom-in several time

Actual Results:
Image disappears at certain zoom level

Expected Results:
Image should not disappear

Setting gfx.direct2d.use1_1 = false helps
[Tracking Requested - why for this release]:
Adding this to Bas' list of d2d regressions.
Flags: needinfo?(bas)
Okay!
Assignee: nobody → bas
Status: NEW → ASSIGNED
Flags: needinfo?(bas)
Can anyone else verify they see this bug? I can't reproduce it. It'd be interesting to know roughly which hardware is experiencing the issues.
Oh wait, is this specific to an actual 64 bit build?
(In reply to Bas Schouten (:bas.schouten) from comment #17)
> Oh wait, is this specific to an actual 64 bit build?

No, I'm using Nightly m-c hourly & Nightly builds
(In reply to Bas Schouten (:bas.schouten) from comment #16)
> Can anyone else verify they see this bug? I can't reproduce it. It'd be
> interesting to know roughly which hardware is experiencing the issues.

I'm using an older HD3200 chipset from AMD/ATI on a HP Pavilion PC running Win7 64bit.

At the moment running cset: 20141107175107 eb0d3b3c0b22  I am no longer able to reproduce the problem on Youtube. 

We should maybe wait till Alice weighs in before marking this as WFM.  No idea when or what may have fixed this.  I have not checked back since around 10/29/14.
This can probably be closed then based on Alice's findings in comment #20.

I would close this as WFM, but I'm not sure what to do with the dependency bug 109608.  I'm not sure that bug is dependent on this one at all.
This problem still reproduced in Aurora35.0a2.
And Bug 1095608 will fix for Aurora35.0a2.
Based on comment 22, there's no reason to keep tracking this for 35.
platform-rel: --- → ?
Whiteboard: [platform-rel-Youtube]
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Version: Trunk → 37 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: