Closed
Bug 845661
Opened 12 years ago
Closed 12 years ago
[Browser] Attention screens don't appear when the browser app's URL bar is focused
Categories
(Firefox OS Graveyard :: Gaia, defect)
Tracking
(blocking-b2g:tef+, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)
People
(Reporter: leo.bugzilla.gaia, Assigned: vingtetun)
References
Details
(Whiteboard: IOT, Spain, Ikura, [TD-8617], Chile, khepera_43442)
Attachments
(1 file)
2.88 KB,
patch
|
daleharvey
:
review+
|
Details | Diff | Splinter Review |
1. Title : Alarm is not shown
2. Precondition : Set an alarm.
3. Tester's Action :
1) Open any page in browser
2) click on the url bar and wait for the alarm to go on.
3) It is observed that only alarm sound is heard. the alarm UI is not visible
4. Detailed Symptom (ENG.) : It is observed that only alarm sound is heard. the alarm UI is not
visible
5. Gaia Version : 6916e18d1f72936e892543cf4a104a7d457f78ad
6. Expected : Alarm UI should be shown.
7.Reproducibility: Y
1)Frequency Rate : 100%
This only happens when 'Browser' is added to outOfProcessBlackList array. It seems there is an issue when opening a new window from an app belonging to the outOfProcessBlackList array in window_manager.js
Repo steps:
1. Launch the alarm app and set the alarm to one minute later.
2. Launch Browser app and touch the address bar.
3. Let the keyboard open and wait until the alarm goes off.
It seems that Justin is an expert on this. Justin, Would you be able to take this bug?
Assignee: nobody → justin.lebar+bug
Comment 3•12 years ago
|
||
Hi, Leo. It's actually considered a bit presumptuous to assign a bug to someone, particularly if you're not their manager. We use bug assignment to indicate that someone is actively working on a bug, so letting people arbitrarily assign bugs to other people would be pretty confusing.
> This only happens when 'Browser' is added to outOfProcessBlackList array.
To be clear, 'Browser' is part of outOfProcessBlackList by default, right?
This sounds to me like a bug in the Gaia window manager, which is not my area of expertise. It would probably be helpful if you could include the output from |adb logcat|; it's possible that we're hitting something that's causing the window manager to throw an exception which would be reported there.
Assignee: justin.lebar+bug → nobody
Hi Justin,
I'm sorry about that. But I had no options, it wasn't my decision to do so.. :( I will inform my people around about that.
Thanks.
Updated•12 years ago
|
Component: Gaia::Browser → Gaia
Updated•12 years ago
|
blocking-b2g: --- → tef?
Updated•12 years ago
|
blocking-b2g: tef? → tef+
Updated•12 years ago
|
Same issue exists when there is an incoming call when a user is using the browser app. This seems critical.
Comment 7•12 years ago
|
||
To clarify the 2 situations that Ian discovered,
1. Before commit 19f1a8f91a624cca07d018b8ad1154d013eb24b6,
the attention screen could be shown for the first time, but not for 2nd+ time.
Note this only occurs for browser app, could not be reproduced with other apps
2. After that patch 19f1a8f91a624cca07d018b8ad1154d013eb24b6,
the attention screen would not be shown every time per the bug description.
If we reverted one the changes in 19f1a8f91a624cca07d018b8ad1154d013eb24b6,
Change the following line, https://github.com/mozilla-b2g/gaia/blob/a186001c3f21181026c686b6aec611feb2ac9fb2/apps/system/js/attention_screen.js#L54
back to
this.attentionScreen.style.height = window.innerHeight + 'px';
Then, for the first time, the attention screen could be shown.
Still not sure why that change makes any difference.
Summary: [Browser] Alarm doesnt show when the url bar is selected. → [Browser] Attention screen could not show up when the URL bar is focused
Comment 8•12 years ago
|
||
(In reply to Rudy Lu [:rudyl] from comment #7)
> To clarify the 2 situations that Ian discovered,
>
> 1. Before commit 19f1a8f91a624cca07d018b8ad1154d013eb24b6,
> the attention screen could be shown for the first time, but not for 2nd+
> time.
> Note this only occurs for browser app, could not be reproduced with other
> apps
For the attention screen could not be shown for 2nd+ time, I find out it's relative with blur app frame. We could reference the commit (a27ca826bf2948ec6342a0f365c384adb48d2fcb). The patch is supported for hiding keyboard while attention screen is showing. If we remove blur app frame, attention screen will work normally. I still have no idea about the root cause.
BTW, is it relative with OOP? Per Rudy's experiment, if we let Browser app be OOP(or let all apps not in OOP), all of the above issues cannot be reproduces. Does someone have any idea?
Comment 9•12 years ago
|
||
Hi all,
Here is an update on the investigation.
1. This issue will occur when the app to show attention screen is not in the same process of the current process with keyboard.
a. Dialer (OOP) + Browser (in-process) => can reproduce, and this is the case in bug description.
Dialer (OOP) + Calendar (in-process, modified for testing) => can reproduce
b. Dialer (OOP) + Browser (OOP, for testing only) => OK
Dialer (OOP) + Calendar (OOP) => OK
c. Move all app. in process
Dialer (in-process) + Browser (in-process) => OK
So, this should be an OOP related issue.
--
Thanks to SC on the investigation support.
Comment 10•12 years ago
|
||
Thanks for Rudy and SC's help. Obviously it's an OOP issue. It may need dev who is relative with OOP to handle it.
Assignee: iliu → nobody
Comment 11•12 years ago
|
||
I wonder how gecko would fix this issue...
Couldn't we find a gaia workaround?
Comment 12•12 years ago
|
||
It's hard to have a workaround for avoided the two issues. BTW, I try to blur the iframe with setTimeout 0s. The attention screen could be showing, but not hide the keyboard. The situation only occurs in Browser app too.
Comment 13•12 years ago
|
||
David, can you find someone to work on this? As Alive says, it would be nice to work around this in gaia. But Ian thinks that might not be possible ...
Assignee: nobody → dscravaglieri
Comment 14•12 years ago
|
||
It is not clear to me what the putative Gecko bug is, other than "an OOP issue". If there's an actual bug here, we should fix it. But someone needs to dig in.
Updated•12 years ago
|
Assignee: dscravaglieri → dale
Comment 15•12 years ago
|
||
Looking into this, so far the only differing log output when we fail to show the attention screen is
I/Gecko ( 1536): [Parent 1536] WARNING: throttled animations not up to date: '!CommonAnimationManager::ThrottlingEnabled() || mPresContext->ThrottledStyleIsUpToDate()', file /Volumes/Boot2Gecko/B2G/gecko/layout/style/nsTransitionManager.cpp, line 503
I/Gecko ( 1536): [Parent 1536] WARNING: throttled animations not up to date: '!CommonAnimationManager::ThrottlingEnabled() || mPresContext->ThrottledStyleIsUpToDate()', file /Volumes/Boot2Gecko/B2G/gecko/layout/style/nsTransitionManager.cpp, line 503
I/Gecko ( 1536): [Parent 1536] WARNING: throttled animations not up to date: '!CommonAnimationManager::ThrottlingEnabled() || mPresContext->ThrottledStyleIsUpToDate()', file /Volumes/Boot2Gecko/B2G/gecko/layout/style/nsTransitionManager.cpp, line 503
I/Gecko ( 1536): [Parent 1536] WARNING: throttled animations not up to date: '!CommonAnimationManager::ThrottlingEnabled() || mPresContext->ThrottledStyleIsUpToDate()', file /Volumes/Boot2Gecko/B2G/gecko/layout/style/nsTransitionManager.cpp, line 503
I/Gecko ( 1536): [Parent 1536] WARNING: throttled animations not up to date: '!CommonAnimationManager::ThrottlingEnabled() || mPresContext->ThrottledStyleIsUpToDate()', file /Volumes/Boot2Gecko/B2G/gecko/layout/style/nsTransitionManager.cpp, line 503
Comment 16•12 years ago
|
||
Should we ask dbaron about the layout log entries?
Comment 17•12 years ago
|
||
nah at this point I am fairly sure its a gaia bug, trying to narrow it down is tricky but should hopefully have it tonight
Comment 18•12 years ago
|
||
Are things still going alright here, Dale? If you're too overloaded we could try to find someone to take it over from you.
Comment 19•12 years ago
|
||
Yeh sorry, I keep getting side tracked but I have time to find this now, not guaranteed tomorrow but definitely before monday
Comment 20•12 years ago
|
||
Hi,
This has been also detected during certification in Spain with ikura.
Adding dep to meta bugs.
Comment 21•12 years ago
|
||
Sorry still working on this, I think it is a z-index problem with stacked in and out of process iframes, trying to make a small test case to reproduce but I keep going down the wrong rabbit hole.
Updated•12 years ago
|
Summary: [Browser] Attention screen could not show up when the URL bar is focused → [Browser] Attention screens don't appear when the browser app's URL bar is focused
Updated•12 years ago
|
Whiteboard: IOT, Spain, Ikura
Assignee | ||
Comment 22•12 years ago
|
||
I have a workaround that let it works. I'm not proud of it and it workaround the gecko issue but that should be fine for now. I will post it a bit later.
Comment 23•12 years ago
|
||
Did you nail down the actual gecko issue?
Assignee | ||
Comment 24•12 years ago
|
||
Here the workaround.
Comment 25•12 years ago
|
||
This workaround looks stable to me, I havent been able to reproduce the bug with it applied.
I am having a hard time tracking down the root bug, it doesnt seem to be just a missing repaint, If I trigger another repaint after a timeout it still doesnt become visible and as far as I can tell the attention screen is in the dom and styled exactly as it should be. There were various workarounds involving settimeouts for the keyboard but viviens is cleaner than anything I came up with.
I think this should be landed, vingetun?
Assignee | ||
Comment 26•12 years ago
|
||
(In reply to Dale Harvey (:daleharvey) from comment #25)
> This workaround looks stable to me, I havent been able to reproduce the bug
> with it applied.
>
> I am having a hard time tracking down the root bug, it doesnt seem to be
> just a missing repaint, If I trigger another repaint after a timeout it
> still doesnt become visible and as far as I can tell the attention screen is
> in the dom and styled exactly as it should be. There were various
> workarounds involving settimeouts for the keyboard but viviens is cleaner
> than anything I came up with.
>
> I think this should be landed, vingetun?
I think the main issue is: something very expensive happens on the main process/thread and expose a race condition in the layout/gfx code. When this expensive operation stops, the app is not repainted but if you force it to be resize (by hitting the home button for example) then it repaints.
Let's use this workaround right now but I would love a new bug to track the platform issue (which is not OOP related since it happens only if the browser application is in-process and so have the priority of the main process).
I think the main issue is something very heavy happens on the main process and it is
Assignee | ||
Updated•12 years ago
|
Attachment #736254 -
Flags: review?(dale)
Comment 28•12 years ago
|
||
Comment on attachment 736254 [details] [diff] [review]
Workaround
Tested this as much as I can, havent been able to reproduce a similiar bug, I filed a bug for platform (https://bugzilla.mozilla.org/show_bug.cgi?id=861799)
Attachment #736254 -
Flags: review?(dale) → review+
Comment 29•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 30•12 years ago
|
||
Uplifted commit 558effceb97a172cd1e6a306d25fbb1484d8c19c as:
v1-train: 8c8d831f6e3371e526e91c443688ff600dc82dfe
v1.0.1: b63ebb468031e741072b9bc99eec86a76ff9b6de
Whiteboard: IOT, Spain, Ikura, TD-8617 → IOT, Spain, Ikura, [TD-8617]
Updated•12 years ago
|
Whiteboard: IOT, Spain, Ikura, [TD-8617] → IOT, Spain, Ikura, [TD-8617], Chile, khepera_43442
Updated•12 years ago
|
Target Milestone: --- → Leo QE1 (5may)
Comment 31•12 years ago
|
||
Verified fixed on inari device with:
Gaia e6d694f86e6a704fce00509de7c65aa976ade9f6
BuildID 20130418004045
Version 18.0
Status: RESOLVED → VERIFIED
Comment 32•12 years ago
|
||
Seems to be working on the certification target, 4/26 partner build for Ikura.
Comment 33•12 years ago
|
||
The contentWindow to check OOP state here seems failed:
Now for every active app, the visibility will be soon turned off.
Updated•12 years ago
|
Updated•12 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•