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?

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.

triage: 1.4+ regression

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

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.

(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

Does this reproduce with tiling disabled, but APZC enabled?

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

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.

This is caused by bug 979489.

(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?

Looked related to bug 985060, but that one is there with tiling disabled as well.

Needs a logcat.

Attached logcat from latest 1.4 nightly

This works as expected for me, gecko r174984. Could you try this again please?

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

(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?

Hi Milan, The issue still occurs with hardware composition off in the developer menu.

Botond, could you take a look as well? Just in case it's on the content side.

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.

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

(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

Right now, it looks like this can be done by the end of the week.

(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.

Try push for my patches: https://tbpl.mozilla.org/?tree=Try&rev=a183b70fbf96

https://hg.mozilla.org/integration/mozilla-inbound/rev/3a9db1874007 https://hg.mozilla.org/integration/mozilla-inbound/rev/d1efe20d0350

https://hg.mozilla.org/mozilla-central/rev/3a9db1874007 https://hg.mozilla.org/mozilla-central/rev/d1efe20d0350

https://hg.mozilla.org/releases/mozilla-aurora/rev/89bbecef9a59 https://hg.mozilla.org/releases/mozilla-aurora/rev/4ce68ff00b85