Closed
Bug 1035114
Opened 7 years ago
Closed 7 years ago
Delayed screen updates when scrolling inside textarea nodes or dropdowns
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
FIXED
mozilla33
People
(Reporter: whimboo, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [will be fixed by bug 1028237])
Attachments
(2 files)
First seen with Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140706004001 CSet: f53099796238 but tracked back until 27.0b1 so far. When I vertically scroll inside some textarea elements, parts of the screen are not updated immediately but it takes about 2-4s. Steps: 1. Open https://wiki.mozilla.org/index.php?title=QA/Automation/Meetings&action=edit§ion=4 and ensure you are logged in, so you can edit the textarea 2. Scroll vertically in that textarea element With step 2 you will notice that parts are not updated immediately. It takes some seconds. This may be dependent on the graphic card, or drivers. In my case I have a Lenovo Thinkpad X230. Graphics card details see below: Adapter Description Intel Open Source Technology Center -- Mesa DRI Intel(R) Ivybridge Mobile Device ID Mesa DRI Intel(R) Ivybridge Mobile Driver Version 3.0 Mesa 10.1.3 GPU Accelerated Windows 0/2 Basic Vendor ID Intel Open Source Technology Center WebGL Renderer Intel Open Source Technology Center -- Mesa DRI Intel(R) Ivybridge Mobile windowLayerManagerRemote false AzureCanvasBackend cairo AzureContentBackend cairo AzureFallbackCanvasBackend none AzureSkiaAccelerated 0
Reporter | ||
Comment 1•7 years ago
|
||
Hm, just tested with latest nightly and it works. Quick test shows that it was fixed on mozilla-central between 06/30 and 07/01: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b6408c32a170&tochange=83c09fe3a658 Daniel, could you check for the range on inbound builds? That would help me a lot. Thanks.
Comment 2•7 years ago
|
||
Here is the regression range from inbound: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0303b2fe5f90&tochange=f79302ac0ede I'm not sure in which bug from those 3 this gets fixed.
Reporter | ||
Comment 3•7 years ago
|
||
Well, this is nothing related to fonts. So bug 1028237 should have fixed that. Matt, would that make sense? Given that bug 1028237 has a different regression range and regressor, I would like to keep this bug separate. It's not related to video controls, and has started with Firefox 27.0b1.
Reporter | ||
Comment 4•7 years ago
|
||
This is a very annoying behavior and makes it very hard to interact with certain elements. I see the same when scrolling through the branch list of Github hosted repositories: https://github.com/mozilla/qa-mozmill-tests/tree/mozilla-aurora Just click the branch dropdown and scroll down. Large parts stay white.
Reporter | ||
Updated•7 years ago
|
Summary: Delayed screen updates when scrolling inside textarea nodes → Delayed screen updates when scrolling inside textarea nodes or dropdowns
Reporter | ||
Updated•7 years ago
|
Whiteboard: [will be fixed by bug 1028237]
Reporter | ||
Comment 5•7 years ago
|
||
Reporter | ||
Comment 6•7 years ago
|
||
Reporter | ||
Updated•7 years ago
|
Attachment #8454300 -
Attachment description: screenshot → screenshot (textarea)
Comment 7•7 years ago
|
||
Yeh, running GNU/Linux too, I had this issue at a few occasions. However, I cannot reproduce your testcase. We have this bug for a while. Not sure we will block the 31 release for that. We can always take a patch if it is minor and very low risk. Tracking for 32.
Reporter | ||
Comment 8•7 years ago
|
||
(In reply to Sylvestre Ledru [:sylvestre] from comment #7) > We can always take a patch if it is minor and very low risk. > Tracking for 32. The patch on bug 1028237 should fix it, given that I cannot see the problem with Firefox 33.0 anymore. So we should put more eyes on getting the patch backported.
Comment 9•7 years ago
|
||
OK. So, let's move this discussion in bug 1028237.
Comment 10•7 years ago
|
||
(In reply to Sylvestre Ledru [:sylvestre] from comment #9) > OK. So, let's move this discussion in bug 1028237. So should this bug be duped?
Reporter | ||
Comment 11•7 years ago
|
||
This bug depends on that fix but was caused by another patch way earlier. So I don't think so, as already mentioned above. I haven't seen the needs to check for the regression range given that a fix is already in place. If you want that please let us know.
Reporter | ||
Comment 12•7 years ago
|
||
Works great now with Aurora too: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140715004003 CSet: d32649a24965
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(matt.woodrow)
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in
before you can comment on or make changes to this bug.
Description
•