Closed Bug 987219 Opened 6 years ago Closed 6 years ago

[B2G][Contacts] E-Mail field is removed then reappears after deleting entry when creating a new contact


(Core :: Graphics: Layers, defect)

30 Branch
Gonk (Firefox OS)
Not set



blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- affected
b2g-v2.0 --- unaffected


(Reporter: tnguyen, Unassigned)




(Keywords: regression)


(2 files)

Attached file logcat
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

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 ;)
Component: Gaia::E-Mail → Gaia::Contacts
Does this happen on 1.3?
Keywords: qawanted
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
Keywords: qawanted
Minor regression.
Keywords: regression

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-b2g: --- → 1.4?
BLocking as this may confuse end users and is a regresssion.
blocking-b2g: 1.4? → 1.4+
Assignee: nobody → gtorodelvalle
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.
QA Contact: jschmitt
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:
Another tiling regression.
Blocks: can-tiles
Component: Gaia::Contacts → Graphics: Layers
Product: Firefox OS → Core
Version: unspecified → 30 Branch
Yeah, here you are a video I recorded with the "Layers: Draw Tile Borders":
Attached file 17708.html
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 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]

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!
Attachment #8397839 - Flags: feedback?(arnau)
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.
Flags: needinfo?(bgirard)
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.
Flags: needinfo?(bgirard)
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
Attachment #8397839 - Flags: review?(jmcf)
Assignee: gtorodelvalle → nobody
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 to see if I could reproduce the issue... And I could :-)

You can find my repository and branch at There you are the basic changes I included: 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:

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! ;-)
Flags: needinfo?(bgirard)
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.
Depends on: 984490
Flags: needinfo?(bgirard)
(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.
Flags: needinfo?(bgirard)
I'm tracking this one.
Flags: needinfo?(bgirard)
Comment on attachment 8397839 [details]

Sorry, cannot reproduce.
Is this fixed in the refreshed layout?
Attachment #8397839 - Flags: feedback?(arnau) → feedback-
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!
Flags: needinfo?(milan)

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.
Flags: needinfo?(milan)
Marking qawanted to retest this on a 4/4/2014 1.4 build or later.
Keywords: qawanted
(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
Keywords: qawanted
No longer blocks: can-tiles
Closed: 6 years ago
No longer depends on: 984490
Resolution: --- → DUPLICATE
Duplicate of bug: 984490
You need to log in before you can comment on or make changes to this bug.