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

(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.

Apparently this build fixes the problem: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-de32e9b7ea2a/try-win32/

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.

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.

Okay!

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.

Fixed range https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f2e96abcf610&tochange=0c50940fd16d Bug 1085187 seems to fix this problem.

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.