Open Bug 1256728 Opened 4 years ago Updated 2 years ago

Chrome content is visually deformed and stretched when I resize window

Categories

(Core :: Graphics, defect, P3)

47 Branch
Unspecified
Windows
defect

Tracking

()

Tracking Status
firefox47 --- fixed
firefox48 --- verified

People

(Reporter: arni2033, Assigned: bas.schouten)

References

Details

(Keywords: regression, Whiteboard: gfx-noted)

Attachments

(3 files)

>>>   My Info:   Win7_64, Nightly 48, 32bit, ID 20160313030418
STR:
1. Open new tab
2. Paste "mailto:dolske@mozilla.org" into urlbar, press Enter
3. Hover mouse over the right border of opened window, hold left mouse button,
   move mouse to the left and right to resize the "Launch application" window

AR:  All text is stretched horizontally. This also happens with Browser toolbox and other windows
ER:  Text shouldn't be deformed

Note:
This is actually very easy to reproduce. It was **** the screencast, because for some reason
FRAPS prevents some bugs from happening by consuming a lot of CPU resources

This is regression from bug 1232042. Regression range:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4e56796fa59b7be8d0ebc717f0a6db410cb3a0fa&tochange=2dd26535e73c160f9ce478cd0561b7722042c0d3
Component: Untriaged → Graphics
Product: Firefox → Core
Whiteboard: gfx-noted
Has Regression Range: --- → yes
Has STR: --- → yes
This sounds like the same problem as bug 1251778
I have this problem too (it has not been fixed by bug 1251778).
It only happens with D3D11 (both with Direct2D on or off).
Disabling HWA or using D3D9 fixes it.
Flags: needinfo?(jmuizelaar)
Patch in comment 3 to verify it is force present that's causing this.
Assignee: nobody → bas
Attachment #8735488 - Flags: review?(bgirard) → review+
Comment on attachment 8735488 [details]
MozReview Request: Bug 1256728: Add environment variable to disable force present from bug 1232042. r?benwa

https://reviewboard.mozilla.org/r/42805/#review39241

Looks fine.

Unrelated to this but it feels a tad abritrary how we use prefs vs environment variables. I feel like this should be an pref since it's more user friendly to flip and it's presumably not something that would need to be done right at startup or cause a build to be 'bricked'. In any case we should gate landing this on that discussion.
Sidenote.

I was debating the envvar vs. pref as well; today, in broad strokes, we have a few different levels of "choices" of what happens at runtime through:

1 Preferences that show up as UI elements (e.g., use hardware acceleration when available)
2 Preferences that show up in about:config by default
3 Preferences that can be set in about:config, but aren't there by default (i.e., not in all.js)
4 Environment variables

At each level, the ease of use decreases, the expertise increases, the ease of removing it in the future goes up.  All of this makes sense.  You don't want something potentially very damaging to be easy to toggle.

I consider environment variables for debugging or really scary stuff, and more to the point, something you probably don't want hanging around except while actively using.  On the other hand, contrary to "not hanging around", the environment variables are not reset when you reset the profile, so that's something to consider.

End sidenote.

In this particular case, I don't expect this to hang around for a long time (famous last words), so I went with the environment variable.
Setting the MOZ_DISABLE_FORCE_PRESENT variable fixes the problem for me.
(In reply to Oriol from comment #8)
> Setting the MOZ_DISABLE_FORCE_PRESENT variable fixes the problem for me.

Thanks for the confirmation - what system do you have, and can you give us the about:support graphics section from that system?
OS: Unspecified → Windows
(In reply to Milan Sreckovic [:milan] from comment #10)
> Thanks for the confirmation - what system do you have, and can you give us
> the about:support graphics section from that system?

I have Windows 10 Pro 64 bit with Intel Graphics 530:
> Adapter Description: Intel(R) HD Graphics 530
> Adapter Drivers: igdumdim64 igd10iumd64 igd10iumd64 igd12umd64 igdumdim32 igd10iumd32 igd10iumd32 igd12umd32
> Adapter RAM: Unknown
> Asynchronous Pan/Zoom: none
> Device ID: 0x1912
> Direct2D Enabled: true
> DirectWrite Enabled: true (10.0.10586.0)
> Driver Date: 2-2-2016
> Driver Version: 20.19.15.4380
> GPU #2 Active: false
> GPU Accelerated Windows: 4/4 Direct3D 11 (OMTC)
> Subsys ID: 00000000
> Supports Hardware H264 Decoding: Yes; Using D3D11 API
> Vendor ID: 0x8086
> WebGL Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics 530 Direct3D11 vs_5_0 ps_5_0)
> windowLayerManagerRemote: true
> AzureCanvasAccelerated: 0
> AzureCanvasBackend: direct2d 1.1
> AzureContentBackend: direct2d 1.1
> AzureFallbackCanvasBackend: cairo
MOZ_DISABLE_FORCE_PRESENT also works on another PC with Windows 10 64 bit. The graphic card is nVidia GeForce 7300 SE/7200 GS but has Microsoft's driver instead of nVidia's because the latter doesn't support Windows 10 officially and only has D3D9.
> Adapter Description: Adaptador de pantalla básico de Microsoft
> Adapter Drivers: Unknown
> Adapter RAM: 0
> Asynchronous Pan/Zoom: none
> Device ID: 0x01d3
> Direct2D Enabled: true
> DirectWrite Enabled: true (10.0.10586.0)
> Driver Date: 6-21-2006
> Driver Version: 10.0.10586.0
> GPU #2 Active: false
> GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
> Subsys ID: 00000000
> Supports Hardware H264 Decoding: No; Failed to create D3D11 device for decoder; CheckDeviceFormatConversion failed with error 8876086A
> Vendor ID: 0x10de
> WebGL Renderer: Google Inc. -- ANGLE (Microsoft Basic Render Driver Direct3D11 vs_5_0 ps_5_0)
> windowLayerManagerRemote: true
> AzureCanvasAccelerated: 0
> AzureCanvasBackend: direct2d 1.1
> AzureContentBackend: direct2d 1.1
> AzureFallbackCanvasBackend: cairo
> (#0) Error: VendorIDMismatch V 0x10de 0x1414
:arni, does using that environment variable fix the problem on your system?  I notice it's Windows 7.
Flags: needinfo?(arni2033)
Since :arni hasn't answered yet and I managed to fix the graphical misconfiguration of my Windows 7 64 bit with AMD Radeon 6290 and so I can reproduce the problem: yes, the variable fixes it for me on Win7 too
> Adapter Description: AMD Radeon HD 6290 Graphics
> Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
> Adapter RAM: 256
> Asynchronous Pan/Zoom: none
> Device ID: 0x9807
> Direct2D Enabled: Blocked for your graphics card because of unresolved driver issues.
> DirectWrite Enabled: false (6.2.9200.17568)
> Driver Date: 11-20-2014
> Driver Version: 14.501.1003.0
> GPU #2 Active: false
> GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
> Subsys ID: 05981025
> Supports Hardware H264 Decoding: Yes; Using D3D9 API
> Vendor ID: 0x1002
> WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6290 Graphics Direct3D11 vs_5_0 ps_5_0)
> windowLayerManagerRemote: true
> AzureCanvasAccelerated: 0
> AzureCanvasBackend: skia
> AzureContentBackend: cairo
> AzureFallbackCanvasBackend: cairo
I never used any "environment variables", but in my understanding it's impossible to set an "environment variable" without a value. And everybody just said "Set the MOZ_DISABLE_FORCE_PRESENT variable" without specifying the value as if it was an obvious thing.
Without instructions clear enough I think I'll just wait for a new build and test it.
Flags: needinfo?(arni2033)
(In reply to arni2033 from comment #15)
> I never used any "environment variables", but in my understanding it's
> impossible to set an "environment variable" without a value. And everybody
> just said "Set the MOZ_DISABLE_FORCE_PRESENT variable" without specifying
> the value as if it was an obvious thing.
> Without instructions clear enough I think I'll just wait for a new build and
> test it.

1. Download a build with this change, e.g. http://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1459204724/
2. Extract the .zip to C:\Path\to\Firefox\
3. Open a console (cmd.exe) and enter
> set MOZ_DISABLE_FORCE_PRESENT=true
> "C:\Path\to\Firefox\firefox\firefox.exe"
I think any non-empty value should work too.
To test without the variable, run the extracted firefox.exe outside that console, or enter
> set MOZ_DISABLE_FORCE_PRESENT=
> "C:\Path\to\Firefox\firefox\firefox.exe"
Yes, setting variable MOZ_DISABLE_FORCE_PRESENT fixes this bug.
It also fixes bug 1256086, which is quite annoying. (Nobody even cared to repdocude that one, right?)
Blocks: 1256086
Bas, is the force present something we should limit to Windows 10, it seems to be causing some regressions on the earlier versions?
Flags: needinfo?(bas)
(In reply to Milan Sreckovic [:milan] from comment #18)
> Bas, is the force present something we should limit to Windows 10, it seems
> to be causing some regressions on the earlier versions?

Tricky, there seem to be some non Win-10 bugs to be fixed by it as well afaiui, but it's not hard to do at least.. This bug should be fixed mostly though. But I guess not. I'll try to reproduce it some more.
Flags: needinfo?(bas)
Possible this is helped by bug 1256547
See Also: → 1256547
(In reply to Milan Sreckovic [:milan] from comment #20)
> Possible this is helped by bug 1256547

I still have the problem.
(In reply to Oriol from comment #21)
> (In reply to Milan Sreckovic [:milan] from comment #20)
> > Possible this is helped by bug 1256547
> 
> I still have the problem.

But your problem goes away with that environment variable set, right?  Bas, should we be doing a force present with WARP?
Flags: needinfo?(jmuizelaar) → needinfo?(bas)
(In reply to Milan Sreckovic [:milan] from comment #22)
> But your problem goes away with that environment variable set, right?

Yes, the environment variable fixes it.
(In reply to Milan Sreckovic [:milan] from comment #22)
> (In reply to Oriol from comment #21)
> > (In reply to Milan Sreckovic [:milan] from comment #20)
> > > Possible this is helped by bug 1256547
> > 
> > I still have the problem.
> 
> But your problem goes away with that environment variable set, right?  Bas,
> should we be doing a force present with WARP?

It would be a bit of a guess that the bugs don't occur with WARP. There's a good chance they don't but it's impossible to know. I'm surprised this race condition actually occurs so frequently, Do we have any local machines that show this symptom?
Flags: needinfo?(bas)
Never mind, I can reproduce it by following instructions closely.
Comment on attachment 8742354 [details]
MozReview Request: Bug 1256728: Don't force presentation during resize. r=jrmuizel

https://reviewboard.mozilla.org/r/47149/#review44303
Attachment #8742354 - Flags: review?(jmuizelaar) → review+
The patch fixes the problem. "leave-open" keyword should be removed, and the bug should be marked as resolved.
I think the environment variable of attachment 8735488 [details] should be removed.
(In reply to Oriol from comment #31)
> I think the environment variable of attachment 8735488 [details] should be
> removed.

Agreed; sometime in release 50 or 51, when it's had enough time on release.
(In reply to Milan Sreckovic [:milan] from comment #32)
> Agreed; sometime in release 50 or 51, when it's had enough time on release.

Why should it reach release?
Not not sure if I'm missing something, but now that the issue has been fixed, the variable is useless.
By the way, firefox47 is affected. Can the patch be uplifted?
(In reply to Oriol from comment #34)
> By the way, firefox47 is affected. Can the patch be uplifted?

Good point.
Bas, let's get this to 47, that's where force present landed.
Flags: needinfo?(bas)
(In reply to Oriol from comment #33)
> (In reply to Milan Sreckovic [:milan] from comment #32)
> > Agreed; sometime in release 50 or 51, when it's had enough time on release.
> 
> Why should it reach release?
> Not not sure if I'm missing something, but now that the issue has been
> fixed, the variable is useless.

We had other manifestations of the same problem, outside of this bug.  There may be more, and this works as a decent triage in the field, and it doesn't hurt.
Comment on attachment 8742354 [details]
MozReview Request: Bug 1256728: Don't force presentation during resize. r=jrmuizel

Approval Request Comment
[Feature/regressing bug #]: Force present
[User impact if declined]: Wiggly graphics during resizing
[Describe test coverage new/current, TreeHerder]: Nightly coverage
[Risks and why]: Low, basically only avoiding a forced present in some cases we didn't used to have anyway.
[String/UUID change made/needed]: None
Flags: needinfo?(bas)
Attachment #8742354 - Flags: approval-mozilla-beta?
Comment on attachment 8742354 [details]
MozReview Request: Bug 1256728: Don't force presentation during resize. r=jrmuizel

Recent regression, Beta47+
Attachment #8742354 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Arni2033, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(arni2033)
Fixed on:   Win7_64, Nightly 49, 32bit, ID 20160426044609

When I resize some chrome window (devtools toolbox or browser window) by dragging the right border, chrome on the left stays still, while chrome on the right simply twitches to new window dimentions, promptly showing black background near the right side of window. Just like before bug 1232042. 

It doesn't look good from description, but that behavior was presented forever (in other applications
too). I don't know why I reported this in the first place - probably because it affected even "lightweight" chrome windows like mailto dialog. Now at least chrome at the left side stays still.
Flags: needinfo?(arni2033)
(In reply to arni2033 from comment #41)
> Fixed on:   Win7_64, Nightly 49, 32bit, ID 20160426044609
> 
> When I resize some chrome window (devtools toolbox or browser window) by
> dragging the right border, chrome on the left stays still, while chrome on
> the right simply twitches to new window dimentions, promptly showing black
> background near the right side of window. Just like before bug 1232042. 
> 
> It doesn't look good from description, but that behavior was presented
> forever (in other applications
> too). I don't know why I reported this in the first place - probably because
> it affected even "lightweight" chrome windows like mailto dialog. Now at
> least chrome at the left side stays still.

Great! Thanks for the verification. For the other issue, we may need a separate bug.
This doesn't apply cleanly to 47, can we get a rebased patch?
Flags: needinfo?(bas)
>>
comm-beta/mozilla/widget/windows/nsWindowGfx.cpp(173): error C2065: 'CompositorBridgeChild': undeclared identifier

Seems to cause a compile error on m-b. Isn't it CompositorChild there?

FRG
backed out for windows bustage like https://treeherder.mozilla.org/logviewer.html#?job_id=1062219&repo=mozilla-beta
Flags: needinfo?(bas)
Messed up the merge, should be good now:

https://hg.mozilla.org/releases/mozilla-beta/rev/ca9f8dc6b030
Flags: needinfo?(bas)
Flags: qe-verify+
Is this fixed?
Flags: needinfo?(bas)
Version: Trunk → 47 Branch
(In reply to Milan Sreckovic [:milan] from comment #48)
> Is this fixed?

In the vast majority of cases it should be, but I believe I have seen it happen. I can't reproduce it at the moment on 47.
Flags: needinfo?(bas)
You need to log in before you can comment on or make changes to this bug.