Closed Bug 1009368 Opened 6 years ago Closed 6 years ago

[settings] Opening settings as an activity fails

Categories

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

x86_64
Windows 7
defect
Not set

Tracking

(blocking-b2g:2.0+, b2g-v2.0 fixed)

RESOLVED FIXED
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- fixed

People

(Reporter: squib, Assigned: alive)

References

Details

(Keywords: regression)

Attachments

(1 file)

I don't really have time to QA this at the moment, but it appears that on gaia/master, opening the settings app as an activity doesn't work. It worked as of 46878e54d551e25dc11f835139407a68cdf2b886.

To reproduce this, go to Settings -> Keyboards -> Built-in Keyboard and then try to hit the back button. Nothing happens.
Regression from https://bugzilla.mozilla.org/show_bug.cgi?id=994533 ?
Component: Gaia::Settings → Gaia::System::Window Mgmt
Possibly? Unless GitHub is reordering things, the only commits after 46878e... are for bug 973456 and bug 846909.
@Alive,

I just found the problem when bisecting : 

9866a25cab96cb2eab2a808d40da87b4aa68cc3a is the first bad commit
commit 9866a25cab96cb2eab2a808d40da87b4aa68cc3a
Author: Alive Kuo <alegnadise@gmail.com>
Date:   Fri May 9 13:08:41 2014 +0800

    Bug 1007574 - Ready right away if screenshot is protecting the frame

Hope this can help you know the root cause better.
Flags: needinfo?(alive)
Blocks: 960329
Thanks, fixing
Assignee: nobody → alive
Flags: needinfo?(alive)
Blocks: 1007574
blocking-b2g: --- → 2.0?
The settings app seems to call postResult and makes window management to display the keyboard app again.
Another weird result from settings<->keyboard implementation..
The root cause is settings app calls activity.postError when it found the panel name is not passed in the activity when keyboard invokes.
This is not a regression from screenshot ready check but a bug due to keyboard app change from long time ago to pretend to 'back to settings'.
Attachment #8422042 - Flags: review?(timdream)
Cool, now my tests in bug 960329 pass! Removing dependency...
No longer blocks: 960329
blocking-b2g: 2.0? → 2.0+
Comment on attachment 8422042 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/19215

Please try the following STR to see if anything regressed:

1. Launch keyboard settings from Settings
2. Go back
3. Press home key

Expected:

1. See home screen

Unexpected:

1. Either keyboard settings or settings being launched incorrectly at this point.
Attachment #8422042 - Flags: review?(timdream) → review+
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #8)
> Comment on attachment 8422042 [details] [review]
> https://github.com/mozilla-b2g/gaia/pull/19215
> 
> Please try the following STR to see if anything regressed:
> 
> 1. Launch keyboard settings from Settings
> 2. Go back
> 3. Press home key
> 
> Expected:
> 
> 1. See home screen
> 
> Unexpected:
> 
> 1. Either keyboard settings or settings being launched incorrectly at this
> point.

Nothing regressed, merging.
https://github.com/mozilla-b2g/gaia/commit/6d8e117f636da82608b6e0f751cf8c274e556d46
Status: NEW → RESOLVED
Closed: 6 years ago
Component: Gaia::System::Window Mgmt → Gaia::Keyboard
Resolution: --- → FIXED
Strange... now I'm seeing that when you hit the "back" button from the keyboard settings, it seems to turn the settings page into a popup (sort of). The back button becomes an X instead...

There's got to be a way to tell the system to take us back to whatever app opened us. Maybe Haida allows this somehow? Any ideas?
By specifying the target, settings app assumes that it is going to handle the activity but what we want is actually going back to the settings app. This issue is being tracked by bug 1016280.
I meant specifying "section" instead of "target".
You need to log in before you can comment on or make changes to this bug.