1114534 - Blurred rendering when a page is scrolled with up-down keys

Status: RESOLVED WORKSFORME

(Core :: Panning and Zooming, defect, P1)

Description

[Alexander]

Attachment: scrollingtest.zip

When a page is scrolled with up-down keys, the bottom part of the page gets rendered blurred.
To have the blurred content be rendered normally, one has to touch the page.

Steps to reproduce:
1. Load emulator.
2. Load test application (attached here as "scrollingtest.zip").
3. Press ArrowDown and ArrowUp on keyboard frequently.
4. Press ArrowDown.

Actual result:
UI is corrupted, part of the application's screen is blurred.

Expected result:
Page is rendered normally.

Notice, the issue is not reproduced on a Simulator in WebIDE.

Comment 1

[Alexander]

Attachment: ui_corruption_latest.swf - a video of the bug

Comment 2

[Alexander]

Attachment: ui_corruption_screen.png - a screenshot for the issue in Emulator

Comment 3

[Marco Chen [:mchen]]

Hi Kartikaya,

According to [1], I would like needinfo you for the help on this bug.
Thanks.

[1] Bug 993473 - [meta] Enable low-res and progressive tiling on B2G

Hi Alexander,

Thanks for providing the test app and video for understanding the issue.
Could you also provide what version you found this issue? (ex: commit id and which branch)

Thanks.

Comment 4

[Alexander]

In my B2G/ARM emulator I see the following information:
  OS version - Boot2Gecko 2.2.0.0-prerelease;
  platform version - 36.0a1 .

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Proper support for scrolling with keyboard input is something we have not got around top implementing on B2G because afaik there are no actual devices that require this and fixing it just for the emulator is pretty low-priority. It is a bug though and we should fix it eventually.

Comment 6

[Kai-Chih Hu [:khu]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #5)
> Proper support for scrolling with keyboard input is something we have not
> got around top implementing on B2G because afaik there are no actual devices
> that require this and fixing it just for the emulator is pretty
> low-priority. It is a bug though and we should fix it eventually.

Thanks for the information. Do we know the possible estimation of efforts here? This bug is related to a possible incoming device launch which is named red-tai. Can we get your professional feedback to know when and how we can improve this? Thanks.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Keyboard events can be intercepted by web content, same as touch and mousewheel events. The difference is that generally keyboard event listeners cover the entire page, so if we deal with them in APZ the same as we do touch event listeners it means many pages will fall back to synchronous scrolling. That's obviously not desirable. My suggestion here would be to not use APZ scrolling at all for keyboard input, and just do main-thread scrolling. I'm actually not entirely sure what's happening in the code right now for keyboard input on B2G but as a conservative estimate I'd say two weeks to figure it out and fix the behaviour so we don't end up with blurry rendering.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

Is this reproducible on an actual device, or just an emulator problem?  I'm guessing the emulator given that we're talking about arrow keys, but wanted to be sure.  If it's just emulator, it should not be a blocker, and I don't see it being important - just don't use the arrow keys, we don't have them on the devices anyway.  I'm also not sure why it's being tracked, so there may be some information I'm missing, please renominate if I missed something.

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

Stay tuned for a better breakdown of work and tighter estimates.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

I tried to reproduce this bug in the emulator locally and was unable to. As far as I can tell scrolling via the up/down buttons in the emulator works just fine. Looking at the code in your sample app which intercepts those events and does a scrollTo I suspect that this bug is really just a tiling/low-precision bug and has nothing to do with input events. If you can reliably reproduce the problem I'm happy to guide you through fixing it, I would still estimate about 2 weeks to isolate the problem and have a patch.

That being said, if you are looking at targeting devices that don't have touch-screens, there are going to be other problems that you run into, such as not being able to do pinch-zoom. If the device only has a keyboard and no mouse/pointing device navigating is going to be quite painful, and even if it does have a mouse I don't really know what state the mouse input code is in on B2G and whether it's hooked up to everything it needs to be.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Based on the non-reproducibility in comment 10 and lack of further response (and eventual death of red-tai) I'm going to close this as WFM. Please reopen if it's still an issue.