Closed
Bug 1113197
Opened 10 years ago
Closed 10 years ago
Browser hangs when resize window if in-content preferences or about:config is shown
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1117925
People
(Reporter: alice0775, Unassigned)
Details
(Keywords: hang, regression)
Attachments
(1 file)
(deleted),
image/png
|
Details |
Steps To Reproduce:
1. Click "Change Search Setting" from SearchBar to open Search in-content preferences
2. Click "Content" and then click "Search" to toggle pane of in-content preferences
3. Click Maximize button of window contorols at the top-right window
Actual Results:
Browser hangs
Reporter | ||
Updated•10 years ago
|
Summary: Browser hangs when resize window after switching pane of in-content preferences → Browser hangs when resize window if Search in-content preferences is shown
Reporter | ||
Comment 1•10 years ago
|
||
OR
Steps To Reproduce:
1. Maximized browser and restart
2. Click Restore button of window contorols at the top-right window
3. Click "Change Search Setting" from SearchBar to open Search in-content preferences
4. Click Maximize button of window contorols at the top-right window
Actual Results:
Browser hangs
Reporter | ||
Comment 3•10 years ago
|
||
[Tracking Requested - why for this release]:
Reporter | ||
Comment 4•10 years ago
|
||
Stack using crashfirefox.exe : bp-0ad2d70d-4760-4c78-bfd6-357ac2141218
Reporter | ||
Comment 5•10 years ago
|
||
The hang happens with a high probability when I perform steps in Comment#0 and/or Comment#1.
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2a61df4eaa2d&tochange=24ba8274ed60
Flags: needinfo?(bas)
Reporter | ||
Comment 6•10 years ago
|
||
Not rerated to "Search" pane.
Just open in-content preferencesor about:config.
No longer blocks: 1106559
Summary: Browser hangs when resize window if Search in-content preferences is shown → Browser hangs when resize window if in-content preferences or about:config is shown
Reporter | ||
Comment 7•10 years ago
|
||
And, The hang seems to occur only in Windows7 Classic style.
Reporter | ||
Comment 8•10 years ago
|
||
And, also in Windows7 Basic style.
Reporter | ||
Comment 9•10 years ago
|
||
Reporter | ||
Comment 10•10 years ago
|
||
Graphics
--------
Adapter Description: AMD Radeon HD 6450
Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 1024
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 200
Device ID: 0x6779
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16571)
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: 23111787
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6450 Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
Keywords: regression
Reporter | ||
Comment 11•10 years ago
|
||
in local build
Last Good: 2a61df4eaa2d
First Bad: 823227372483
Regressed by:
823227372483 Bas Schouten — Bug 1107297: Only recomposite the damaged rect with D3D11. r=jrmuizel This patch makes us behave similarly to when we're using the BasicCompositor, essentially we will clip all drawing to the final display to the area that was labeled as invalid. When DXGI 1.2 is available we will then also report the damaged area to the Present call so that can then be used to minimize the amount of bits that actually need to be blitted to the screen. Since we're no longer recompositing the whole screen this means we should also only clear the damaged area of the window.
Blocks: 1107297
Reporter | ||
Comment 12•10 years ago
|
||
WORKAROUND: Enable TitleBar
Updated•10 years ago
|
Reporter | ||
Comment 13•10 years ago
|
||
Toggle "Show desktop" button(on the button at the far right end of the taskbar) helps.
So, The problem isthat Nightly37 does not correctly update own window.
This is very annoyance.
Reporter | ||
Updated•10 years ago
|
Component: Widget: Win32 → Graphics: Layers
Reporter | ||
Comment 14•10 years ago
|
||
[Tracking Requested - why for this release]:
status-firefox38:
--- → affected
tracking-firefox38:
--- → ?
Updated•10 years ago
|
Comment 15•10 years ago
|
||
Bas,
Can you look at this?
Reporter | ||
Comment 16•10 years ago
|
||
This seems ro be fixed by Bug 1117925 in m-c
Reporter | ||
Comment 17•10 years ago
|
||
s/ro/to
Reporter | ||
Comment 18•10 years ago
|
||
Confirmed it fixed
https://hg.mozilla.org/mozilla-central/rev/06b590bf59f4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 ID:20150121141530
Status: NEW → RESOLVED
Closed: 10 years ago
tracking-firefox37:
+ → ---
tracking-firefox38:
+ → ---
Resolution: --- → DUPLICATE
Updated•10 years ago
|
No longer blocks: ship-incontent-prefs, 1107297
status-firefox36:
unaffected → ---
status-firefox37:
affected → ---
status-firefox38:
affected → ---
Flags: needinfo?(bas)
You need to log in
before you can comment on or make changes to this bug.
Description
•