Closed Bug 984490 Opened 6 years ago Closed 6 years ago

[B2G][Contacts]Certain contact fields disappear when swiping in the field box

Categories

(Core :: Graphics: Layers, defect)

30 Branch
ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla31
blocking-b2g 1.4+
Tracking Status
firefox29 --- wontfix
firefox30 --- fixed
firefox31 --- fixed
b2g-v1.3 --- unaffected
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: astole, Assigned: botond)

References

()

Details

(Keywords: regression)

Attachments

(4 files)

The Carrier, Email, Street, and Country fields disappear after swiping in the field box while editing a new or previous contact.

Repro Steps:
1) Update a Buri to BuildID: 20140317040204
2) Open Contacts app
3) Press the '+' to create a new contact
4) Type in one of the field boxes listed in the Description until the letters start to scroll
5) Swipe right in the field box to scroll through the letters/characters

Actual:
The letters and/or characters disappear

Expected:
The user is able to scroll through what was typed in the field box

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140317040204
Gaia: 8f802237927c7d5e024fb7dca054dd5efef6b2e6
Gecko: 25cfa01ba054
Version: 30.0a1
Firmware Version: v1.2-device.cfg

Repro frequency: 100%
See attached: Video
What happens on 1.3?
Keywords: qawanted
This issue does not occur on the latest 1.3. The user is able to scroll through what was typed in the field box.

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140317004001
Gaia: 0ab8a9cbcef5f23cec904a3d7f7675e44de29951
Gecko: f824e9d91a2d
Version: 28.0
Firmware Version: v1.2-device.cfg
Probably a gecko regression.
blocking-b2g: --- → 1.4?
triage: 1.4+ regression
blocking-b2g: 1.4? → 1.4+
To be honest, I don't have idea what it is happening here. It seems a gecko issue but no idea. I would say that name and last name fields work properly and they are static (they belong to initial markup). The rest of fields are added to the DOM dynamically. Any suggestion Vivien? or maybe you could know about the correct person to take care of this issue. Thanks a lot
Flags: needinfo?(21)
Can you disable APZC and Tiling and see if you can reproduce ? The 2 options are in the developer menu in the Settings app.

You likely need to restart the phone.

If you can't reproduce with that, that's likely a APZC or tiling issue, and you may want to needinfo kats.
Flags: needinfo?(21)
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #6)
> Can you disable APZC and Tiling and see if you can reproduce ? The 2 options
> are in the developer menu in the Settings app.
> 
> You likely need to restart the phone.
> 
> If you can't reproduce with that, that's likely a APZC or tiling issue, and
> you may want to needinfo kats.

Vivien,

Thanks man for your support

Kats,

The issue is not reproducible when both flags are disabled
Flags: needinfo?(bugmail.mozilla)
QA Contact: bzumwalt
Does this reproduce with tiling disabled, but APZC enabled?
Component: Gaia::Contacts → Graphics
Product: Firefox OS → Core
Version: unspecified → 30 Branch
Inbound Regression Window

Last Working Inbound Build:
Environmental Variables:
Device: Buri v1.4 Mozilla Inbound
BuildID: 20140310192240
Gaia: a351fe62c11737c722ad33aaff438f6ccd00bd4a
Gecko: cafc246cc62c
Version: 30.0a1
Firmware Version: v1.2-device.cfg


First Broken Inbound Build:
Environmental Variables:
Device: Buri v1.4 Mozilla Inbound
BuildID: 20140310204542
Gaia: a351fe62c11737c722ad33aaff438f6ccd00bd4a
Gecko: c234a1aeaeab
Version: 30.0a1
Firmware Version: v1.2-device.cfg

Gaia/Gecko Swap Tinderbox Results

Last Working Gaia/First Broken Gecko: Issue DOES Reproduce:
Gaia: a351fe62c11737c722ad33aaff438f6ccd00bd4a
Gecko: 9cdaf3f7c601

First Broken Gaia/Last Working Gecko: Issue Does NOT Reproduce:
Gaia: a351fe62c11737c722ad33aaff438f6ccd00bd4a
Gecko: 41d962d23e81

Appears to be a Gecko issue

Tinderbox Gecko Pushlog: http://hg.mozilla.org//mozilla-central/pushloghtml?fromchange=41d962d23e81&tochange=9cdaf3f7c601

Inbound Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cafc246cc62c&tochange=c234a1aeaeab
Keywords: qawanted
Keywords: qawanted
Developer setting "Layers: Enable Tiles" has been disabled and APZC has been enabled throughout regression window check above. This DOES reproduce with Tiling disabled and APZC enabled.
Keywords: qawanted
This is caused by bug 979489.
Blocks: can-tiles
Component: Graphics → Graphics: Layers
(In reply to Brogan Zumwalt from comment #10)
> Developer setting "Layers: Enable Tiles" has been disabled and APZC has been
> enabled throughout regression window check above. This DOES reproduce with
> Tiling disabled and APZC enabled.

I don't think that's the right analysis here - tiling should be enabled by default on the latest 1.4 build.
On today's latest 1.4 nightly, tiling is enabled by default. The builds in the regression window appear to occur before tiling was enabled by default (as per comment 11). Apologies for the confusion.

Testing on today's 1.4 nightly build shows that the issue does NOT occur with Tiling Disabled and APZC Enabled.

Environmental Variables:
Device: Buri v1.4 Mozilla RIL
BuildID: 20140318000203
Gaia: c03a6af9028c4b74a84b5a98085bbb0c07261175
Gecko: 3776f72f1967
Version: 30.0a2
Firmware Version: v1.2-device.cfg
Chris, can you take a look?
Assignee: nobody → chrislord.net
Flags: needinfo?(bugmail.mozilla)
Looked related to bug 985060, but that one is there with tiling disabled as well.
Needs a logcat.
Keywords: qawanted
Attached file Logcat
Attached logcat from latest 1.4 nightly
Keywords: qawanted
Duplicate of this bug: 987409
This works as expected for me, gecko r174984. Could you try this again please?
Flags: needinfo?(astole)
Keywords: qawanted
This issue still reproduces for me on the latest 1.4

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140325000201
Gaia: a2a88d0638594a6510f878d2c5e99a6ead7520ad
Gecko: 67bdb575d833
Version: 30.0a2
Firmware Version: v1.2-device.cfg
Flags: needinfo?(astole)
Keywords: qawanted
(In reply to Andrew Stole from comment #20)
> This issue still reproduces for me on the latest 1.4
> 
> 1.4 Environmental Variables:
> Device: Buri 1.4 MOZ
> BuildID: 20140325000201
> Gaia: a2a88d0638594a6510f878d2c5e99a6ead7520ad
> Gecko: 67bdb575d833
> Version: 30.0a2
> Firmware Version: v1.2-device.cfg

I wouldn't rule out this being bug 984618 - I'll try to get a newer firmware on my buri, but I can't currently reproduce it.
Andrew, if you turn off hardware composition in the developer menu, does the problem go away?
Flags: needinfo?(astole)
Hi Milan, 

The issue still occurs with hardware composition off in the developer menu.
Flags: needinfo?(astole)
Botond, could you take a look as well?  Just in case it's on the content side.
Flags: needinfo?(botond)
I can reproduce the problem and confirm that it happens when the input field is layerized. There's nothing obvious that indicates this is an APZ problem, but I can investigate further. (I'm currently experiencing a recurring IPC crash in the Contacts app; building latest master now in the hope that it's fixed.)
I don't understand why not, but I still can't reproduce this problem on m-c (r175323)... It all works fine. Reassigning to Botond based on comment #25.
Assignee: chrislord.net → botond
I investigated this further, and this is what I found:

  - The problem only happens when tiling is enabled.

  - When the input field is layerized, its container layer has a
    *mask layer*, which in turn causes the container layer to use
    an intermediate surface. Hacking the code to disable this (by 
    adding 'useIntermediateSurface = false' just before [1]) makes 
    the problem go away, even with tiling enabled.

This suggests that this is a gfx issue involving some interaction between tiling and mask layers / intermediate surfaces.

I also noticed a separate (and much less severe) issue, where, in the configurations where this bug did not reproduce (i.e. tiling disabled, or tiling enabled but intermediate surfaces disabled), scrolling the input field resulted in checkerboarding, even though the displayport for the input field was the entire scrollable rect (which means there should be no checkerboarding). I'll file a separate bug for this.

[1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.cpp#986
Flags: needinfo?(botond)
(In reply to Chris Lord [:cwiiis] from comment #26)
> I still can't reproduce this problem on m-c (r175323)... It all works fine.

Which input field were you using? I found I had to use a phone number field rather than a name field to reproduce the bug.
With BenWa's help I came up with a reduced test page that shows the problem in the B2G browser. STR is just to scroll the input field to force it to layerize.
Further investigation revealed the following:

  - When a container layer doesn't use an intermediate surface,
    it draws its child layers directly into the frame buffer.

  - When a container layer uses an intermediate surface, it draws
    its child layers onto the intermediate surface, and then
    draws the intermediate surface together with other effects
    (such as a mask) into the frame buffer.

  - Debugging with apitrace revealed that, when not using the
    intermediate surface, the text inside the input field is
    drawn to the frame buffer correctly. However, when using the
    intermediate surface, the text inside the input field is not
    drawn to the intermediate surface at all!

       --> This tells us the problem is not with the application
           of a mask, but with the use of an intermediate
           surface to begin with.

  - The call to TiledContentHist::RenderTile() which is supposed
    to draw the text to the intermediate surface is exiting
    early here [1]. The reason is that a coordinate system
    mismatch: the clip rect is in the coordinate system of the
    intermediate surface, while 'quad' is in the coordinate
    system of the page. This mismatch leads to the two rects
    not intersecting, and the early exit being taken.

Most likely 'quad' should be in the coordinate system of the
intermediate surface as well, we just fail to make this so.
I will check to see how the non-tiled content host (where this
bug does not occur) handles this, and implement corresponding
logic in the tiled content host.

[1] http://dxr.mozilla.org/mozilla-central/source/gfx/layers/composite/TiledContentHost.cpp?from=TiledContentHost.cpp#353
Blocks: 987219
Right now, it looks like this can be done by the end of the week.
Whiteboard: [ETA: 4/4]
(In reply to Botond Ballo [:botond] from comment #30)
> Most likely 'quad' should be in the coordinate system of the
> intermediate surface as well, we just fail to make this so.
> I will check to see how the non-tiled content host (where this
> bug does not occur) handles this, and implement corresponding
> logic in the tiled content host.

In the non-tiled content host, 'quad' is still in the coordinate
system of the page while the clip rect is in the coordinate system
of the intermediate surface, but the content host does compare the
two itself; rather, it hands them off, together with the rendering
target's origin (which is the intermediate surface's offset relative
to the page) to the shader program, which then uses them together
correctly.

After talking to :nical I decided the best way to deal with this is
to modify Compositor::ClipRectInLayersCoordinates() to return the
clip rect in the coordinate system of the page by adding the
rendering target's origin. The attached patches implement this.
(In reply to Botond Ballo [:botond] from comment #27)
> I also noticed a separate (and much less severe) issue, where, in the
> configurations where this bug did not reproduce (i.e. tiling disabled, or
> tiling enabled but intermediate surfaces disabled), scrolling the input
> field resulted in checkerboarding, even though the displayport for the input
> field was the entire scrollable rect (which means there should be no
> checkerboarding). I'll file a separate bug for this.

My patches do not solve this problem, so I filed bug 990974 for this.
Attachment #8400467 - Flags: review?(nical.bugzilla) → review+
Attachment #8400468 - Flags: review?(nical.bugzilla) → review+
No longer blocks: 987219
Duplicate of this bug: 987219
No longer depends on: 993066
You need to log in before you can comment on or make changes to this bug.