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)

27 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla33
Tracking Status
firefox30 --- wontfix
firefox31 - affected
firefox32 + verified
firefox33 - verified
firefox-esr24 --- unaffected

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&section=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
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.
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.
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.
Depends on: 1028237
Flags: needinfo?(matt.woodrow)
Keywords: regression
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.
Summary: Delayed screen updates when scrolling inside textarea nodes → Delayed screen updates when scrolling inside textarea nodes or dropdowns
Whiteboard: [will be fixed by bug 1028237]
Attachment #8454300 - Attachment description: screenshot → screenshot (textarea)
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.
(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.
OK. So, let's move this discussion in bug 1028237.
(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?
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.
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.