Description: The Email field goes away and then reappears after deleting the entry. Repro Steps: 1) Updated Buri to BuildID: 20140324000202 2) Navigate to Contacts app 3) Tap on the '+' to add new contact 4) Enter an email address into the Email field 5) Tap on the delete button to remove entered E-mail Actual Result: Email field momentarily goes away then reappears several seconds later Expected Result: Email field is always displayed Environmental Variables: Device: Buri v1.4 mozRIL BuildID: 20140324000202 Gaia: 730670951e40b2317a167fcd07c398bb662d6e87 Gecko: a44f8b39c2c8 Version: 30.0a2 v1.2-device.cfg URL: http://youtu.be/0gRrYyf54H4 Attached: logcat Note: The email field doesn't reappear sometimes. Repro Frequency: 3/5 (60%)

I think you meant to file this in contacts since everything takes place inside the contacts app. Also, if it's possible to turn off the music in these videos, I think it would be desirable. The videos end up having ads pop up over them, which I assume is a byproduct of youtube's monetization mechanism detecting a song that someone has asserted copyright over and then applying their monetization requests. Also, I don't like the music ;)

Does this happen on 1.3?

This issue does not reproduce on the latest Buri v1.3 mozRIL Build ID: 20140324004001. Gaia: f7742fb4929cc57c9f72955ce5cebb8279745ac0 Gecko: e42b778a010f Version: 28.0 Firmware Version: v1.2-device.cfg

Minor regression.

Hi, Just adding that it also occurs on today's (3/25) master build: Device: Hamachi BuildId: 20140325064012 Gecko: b31f92b Gaia: 5c0b527 Platform version: 31.0a1

Bad user experience (it seems the email address has not been deleted) and regression so nominating to v1.4?

BLocking as this may confuse end users and is a regresssion.

Hi guys! As part of my analysis and using today's master build (Gecko-618b2c2.Gaia-0c9701c), I saw that it happens 100% of the cases when the typed email is longer than the available space. Using a@b.c works fine for me always.

On the other hand and as already mentioned to José Manuel, it happens no matter which field is entered (email, phone number, carrier, address and even comment (which BTW is a special case since it does not have a tag or type on its left-hand side), always if the typed text is bigger than the available space.

Mozilla Inbound Last Working: Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140310192240 Gaia: a351fe62c11737c722ad33aaff438f6ccd00bd4a Gecko: cafc246cc62c Version: 30.0a1 Firmware Version: V1.2-device.cfg First Broken: Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140310204542 Gaia: a351fe62c11737c722ad33aaff438f6ccd00bd4a Gecko: c234a1aeaeab Version: 30.0a1 Firmware Version: V1.2-device.cfg The Gaias are the same so this is a Gecko issue. Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cafc246cc62c&tochange=c234a1aeaeab

Another tiling regression.

Yeah, here you are a video I recorded with the "Layers: Draw Tile Borders": http://youtu.be/6dlyWHUzXFI

Kind of a minimal patch but it solves the issue. I have tested in on the v1.4 since using master I am not currently being able to get the system started :-s BTW, the opacity property was being applied on the div elements (see https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/elements/form.html#L30) and as far as I can see, I do not identify any visual difference regarding applying it or not. I'll show it to some UX more exercised eyes to cross check it :-)

Comment on attachment 8397839 [details] 17708.html Hi Arnau, would you be so kind of having a look at the patch and compare it with the current implementation? I used 2 Hamachi phones and I didn't notice any difference, apart from the bug being fixed :p Thanks!

I don't know why a contacts patch is being posted here. The regression range points this to be a tiling bug, not a Contacts bug.

Hi Jason. I just found an easy way to fix the issue on the Gaia side but totally agree to have some backend guy to have a look at the tiling issue. Does anyone know whom we should need-info here? Thanks!

Yes, Benoit was going to look at this.

Is it possible to get a reduce test case? If removing the opacity fixes the problem it could be a bug with tiling + intermediate surfaces and be a dupe off the bug that botond is looking into.

as per comment #18 cancelling my review until it can be determined what's the real cause of the bug, which seems to be a gpx issue

Hi guys! I found so time to prepare a reduced test case as Benoit suggests ;-) In fact, I also wanted to check if the issue could be related to the Contacts app, and the consequence is that it is not :-) Basically, what I did was to fork the Building Blocks repository at https://github.com/buildingfirefoxos/Building-Blocks to see if I could reproduce the issue... And I could :-) You can find my repository and branch at https://github.com/gtorodelvalle/Building-Blocks/tree/contacts-bug-987219-the-ghost-tag-field-case There you are the basic changes I included: https://github.com/gtorodelvalle/Building-Blocks/compare/contacts-bug-987219-the-ghost-tag-field-case?expand=1 I only include a listener for the legend elements in the input areas which when clicking on them toggles the opacity of the parent node. The result can be found in the following video: http://youtu.be/EIi8a_yupyE Benoit, if you want me to update the code in any sense, please feel free to ask me for it, or tune the code to your needs, of course ;-) Hope that helps! ;-)

Ok. I started working on this bug yesterday and I think it's related to a bug that Botond was working on. We've been collaborating on a solution I'm quite confident will turn out to be the same issue. Standing by for that fix to be completed.

(In reply to Benoit Girard (:BenWa) from comment #21) > Ok. I started working on this bug yesterday and I think it's related to a > bug that Botond was working on. We've been collaborating on a solution I'm > quite confident will turn out to be the same issue. Standing by for that fix > to be completed. It's probably a dupe, but we can retest after landing.

(In reply to Benoit Girard (:BenWa) from comment #21) > Ok. I started working on this bug yesterday and I think it's related to a > bug that Botond was working on. We've been collaborating on a solution I'm > quite confident will turn out to be the same issue. Standing by for that fix > to be completed. Hi, Benoit, then, can you be the owner/assignee for this bug? Thanks.

I'm tracking this one.

Comment on attachment 8397839 [details] 17708.html Sorry, cannot reproduce. Is this fixed in the refreshed layout?

Arnau is completely right. The issue does not reproduce in master (Gecko-011a30c.Gaia-9b73892) after landing the new refreshed layout of the contact form. I am not able to reproduce it in v1.3 (Gecko-648e62e.Gaia-c5cd3a1) either (although I think we already knew that), not even enabling the "Layers: Enable Tiles" and "Layers: Draw Tile Borders" settings. Although it is also true that I am not able to see those borders shown :-S Sadly, it still reproduces in v1.4 (Gecko-805e11a.Gaia-61c502c). I guess Milan is on it ;-) In fact, Milan, do you consider it appropriate to assign the bug to yourself? Just to have it assigned to someone who is working on it or tracking it ;-) I thought it could be somehow rude to do it myself without asking :-) Thanks!

Hi, Since it is not occurring anymore on master (v1.5) due to the new contact from layout, removing that branch as affected. Thanks!

Just to reiterate the information from comment 21 and comment 22. We believe this to be a duplicate of bug bug 984490. The fix for that landed on central on 4/2, so I would expect it in the nightly build that one can run "today" (4/3). It has not yet been uplifted to aurora, but I expect that before the end of the week. It seems this bug was fixed a different way in the central, so we will have to wait until bug 984490 shows up in aurora before it can be tested. Once tested there, assuming this bug is fixed, we can mark this one as duplicate or follow up otherwise. Unassigned doesn't mean nobody is looking at it, it just means nobody is working on it - in this case, because we don't think there is any work on it. I look at all 1.4+ bugs daily.

Marking qawanted to retest this on a 4/4/2014 1.4 build or later.

(In reply to Jason Smith [:jsmith] from comment #29) > Marking qawanted to retest this on a 4/4/2014 1.4 build or later. Following the repro steps in Comment 0, I am unable to repro this issue on the 4/4/2014 1.4 Build. Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140404000202 Gaia: b4f3b84ec68233a99fd5865c15cfe28aebe26531 Gecko: 3186bbc50050 Version: 30.0a2 Firmware Version: V1.2-device.cfg