Closed Bug 1120447 Opened 9 years ago Closed 9 years ago

Email accounts dropdown menu disappears right away

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1117712

People

(Reporter: gwagner, Assigned: kats)

References

Details

(Keywords: dogfood, regression) 

There is a regression with selecting Email accounts on nightly. The drop down menu to select an email account disappears right away. It works sometimes when I restart the app but afterwards its almost impossible to switch.
I will upload a video if needed.
Keywords: dogfood, regression
I believe this is an issue related to bug 928833. If I set layout.event-regions.enabled to false, then I can open the account list. Note however, I only get one tap to work, after that no taps in that area works.

I also see what I believe to be a variant of this issue by just configuring one account in the email app:

* Set up one account (note that tapping on some of the buttons does not work sometimes, but pressing return on the keyboard will work.
* Once in the message list, tap the menu icon in the upper left corner (the one with three lines in it. This will show the folders.
* Try tapping the second folder in the list.

When I do that with layout.event-regions.enabled as true, I see this in the logcat:

    I/Gecko   (12774): 0xaf01a910 replacing unconfirmed target 0xaa7e3000 with real target 0xb18a6800

and the tap seems to register for the third item.

When multiple accounts are configured, as this bug states, then I think the same issue is in play, but in that case the item below the accounts listing is the Inbox folder, and I think the tap gets registered as Inbox, so the menu closes.

ni? kats, and putting this over in the APZC component.
Component: Gaia::E-Mail → Panning and Zooming
Flags: needinfo?(bugmail.mozilla)
Product: Firefox OS → Core
Yeah, sounds like an APZ bug. Based on the "replacing unconfirmed target" message you saw, I suspect this will be fixed by bug 1117712. I can look it at it tomorrow either way; leaving ni on me for now.
I'll park this with me for now.
Assignee: nobody → bugmail.mozilla
Flags: needinfo?(bugmail.mozilla)
I'm not able to reproduce either comment 0 or comment 1 either before or after bug 1117712 landed. Can you confirm you guys can still repro this on a master build? Do you have any non-default prefs set? Also assuming this is a Flame device, what is the RAM amount set to?
The 3.0 build used in the dupe (bug 1121741) is from before 1117712 landed, so it's still possible that this is fixed by bug 1117712.
Latest master flash-kk master engineering full flame flash does not show this, and sounds like bug 1117712, so duping to that bug, as the one that fixed the issue.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Awesome, thanks for checking!
You need to log in before you can comment on or make changes to this bug.