998215 - [Helix] [APZ] Header is shaking when dragging/scrolling when APZ is enabled

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Widget: Gonk, defect)

Description

[Omega Feng [:Omega] [:馮於懋]]

[Steps To Reproduce]
1. Make sure APZ is enabled.
1. Launch Message (or any apps).
2. Drag/scroll on the screen.
 
[Actual Result]
Header is shaking up and down for 1 pixel.
Video: https://www.youtube.com/watch?v=NXg90CqWhuc

[Expected Result]
Header is not shaking.


Device: Helix
OS Version: 1.5.0.0-prerelease
Platform Version: 31.0a1
Build Identifier: 20140413160202

Comment 1

[Steve Chung [:steveck]]

I think it might be related to resolution because Helix is WVGA device. We may need qa's help first to verify it could be only reproduced on other WVGA device and with previous gecko version.

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

It could be that the window is bigger than the screen of 1px. Can you check the size of the document with the app-manager ? (same thing for the size of the element that contains the header ?)

Comment 3

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

for comment 2

Comment 4

[Omega Feng [:Omega] [:馮於懋]]

I tried on Helix and Hamachi, and it happens on Helix but not on Hamachi.
I don't have other devices, so I need helps on other device testing.

Comment 5

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

I can reproduce this on the helix as well, although the "shaking" amount is even really small. I poked around in the app manager and I see this:

- For the system process, the total height is 533.33px (i.e. 800/1.5)
- The status bar takes up 24px
- So the iframes for the content processes are 509.33px

However, when I look at the content processes (say the Settings app) in the app manager, I see "height:100%" evaluate to 509px.

This means there is .33px unaccounted for, and I think that is what is causing the jitter. I think the correct fix here is probably to ensure that the system process doesn't have a fractional number of CSS pixels as a height or width, which probably makes this a gonk bug.

Comment 6

[Andreas Gal :gal]

NS_IMETHODIMP
nsWindow::Resize(double aX,
                 double aY,
                 double aWidth,
                 double aHeight,
                 bool   aRepaint)
{
    mBounds = nsIntRect(NSToIntRound(aX), NSToIntRound(aY),
                        NSToIntRound(aWidth), NSToIntRound(aHeight));

We already round the size of the widget so I don't think this is a gonk/widget issue.

I agree we should not have a fractional size there but even with that we shouldn't jitter like this. We should handle this rounding situation correctly in APZC. Lets fix both bugs.

Comment 7

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

The method you're referencing operates in LayoutDevice pixel space. The rounding problem is after the conversion to CSS pixel space. (i.e. mBounds / nsWindow::GetDefaultScale()). Based on what I've seen I don't think this is a problem in APZC (although it's possible there are other rounding problems there too). I think somewhere code is assuming that window sizes are going to be integer CSS pixels, which is why the content process thinks height:100% is 509px while the parent process is actually giving it 509.33px.

If this bug is important then I can look into it. I don't think it's the same as bug 1004768 though. And for any given device we should able to tell from the screen resolution and density if it will be affected.

Comment 8

[Doug Sherk (:drs) (inactive)]

This doesn't happen with APZC disabled. I'll investigate this further.

Comment 9

[Doug Sherk (:drs) (inactive)]

Damn, Helix's adb logcat is disabled so I can't get a layers dump. I'll try reproing on other devices by manually adjusting their screen size in gonk. I'd like other suggestions if anyone has any.

Comment 10

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

(In reply to Doug Sherk (:drs) from comment #9)
> Damn, Helix's adb logcat is disabled so I can't get a layers dump.

Yours too? I thought my device was just busted. Depending on what you want out of the layers dump, you might be able to get by with the layers.draw-layer-info pref, it will basically write the layers dump onto the screen.

Comment 11

[Doug Sherk (:drs) (inactive)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #10)
> Yours too? I thought my device was just busted. Depending on what you want
> out of the layers dump, you might be able to get by with the
> layers.draw-layer-info pref, it will basically write the layers dump onto
> the screen.

Yeah, I asked around in the Taipei office. Wayne helped me flash a couple of different base images and it was still disabled. Someone else said that the manufacturer just disabled the service for some reason. I'll try that pref.

Comment 12

[Michael Wu [:mwu]]

Check the bottom of the helix intranet page for the magic incantation to turn logcat back on.

Comment 13

[Doug Sherk (:drs) (inactive)]

(In reply to Michael Wu [:mwu] from comment #12)
> Check the bottom of the helix intranet page for the magic incantation to
> turn logcat back on.

Thanks. After William and I sprinkled some chicken blood on sand and did a rain dance, we got it working.

Comment 14

[Doug Sherk (:drs) (inactive)]

I can't seem to build a working Gecko for Helix. Every time I flash it, it bricks the device. I just get this every few seconds in adb logcat:

E/QCALOG  (  116): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent]
E/QCALOG  (  116): [MessageQ] ProcessNewMessage: [XT-CS] unknown deliver target [OS-Agent]
E/QCALOG  (  116): [MessageQ] ProcessNewMessage: [XTWWAN-PE] unknown deliver target [OS-Agent]

I tried doing a clobber build of Gecko, and clearing my B2G/out and B2G/backup-helix directories.

Comment 15

[Michael Wu [:mwu]]

That's unlikely to be relevant to your problem.

Try these things:

1. Delete comril - /system/b2g/distribution

2. Manually start b2g - adb shell stop b2g && b2g.sh

This will get you access to stdout/stderr.

3. Use run-gdb.sh to figure out where things might be crashing/freezing.

4. Turn on bionic linker debugging - edit http://androidxref.com/4.0.4/xref/bionic/linker/Android.mk#35 and turn LINKER_DEBUGGING to 1. Touch all the c files in the directory to force rebuilding, build, and then push linker into /system/bin. You will brick the device if you screw this up.

Comment 16

[Doug Sherk (:drs) (inactive)]

This is getting too complicated for now since I only have this device until Friday evening. I'm going to hold off on this for now and come back to it once I get a device that I'm not just borrowing.

Comment 17

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

I don't think we care about Helix any more.