967994 - put the browser back in the dock

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

[Dietrich Ayala (:dietrich)]

This really broke development and basic usage (surprisingly fast, actually!).

Comment 1

[Dietrich Ayala (:dietrich)]

Attachment: Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/15958

Comment 2

[Kevin Grandon :kgrandon]

Hey - what's the problem here exactly? This will break other workflows unfortunately. If it's a big issue, we should instead disable rocketbar by default. The patch to do that is only a 1-liner.

Comment 3

[Kevin Grandon :kgrandon]

Rocketbar is being turned on for 1.4, so the more people using it and filing bugs the better. By removing modifyBrowserForRocketbar(), rocketbar flows are essentially broken. So -

If it is *really* broken - let's disable it by default, and figure out what's broken so we can re-enable by default again. We can do this by flipping this 1 to a 0: https://github.com/mozilla-b2g/gaia/blob/master/Makefile#L83

If it just needs improvement (which we are working on), let's ensure that all necessary bugs are filed.

Was there some discussion that I missed here?

Comment 4

[Jason Smith [:jsmith]]

Note - the old browser is still technically accessible here via taking advantage of the known bug in bug 967162.

Comment 5

[Dietrich Ayala (:dietrich)]

Kevin, is all of the browser functionality available via Rocketbar now?

The problem I hit immediately was not being able to edit a URL once typed in. Typing a URL is painful enough, but having to do it all over again really hurt ;)

I also cannot load pages via Rocketbar - just get a white screen in the wrapper.

Basically, we shouldn't remove the browser until the Rocketbar can be used as it's replacement. Not having a browser in the default builds is not only confusing and painful for developers, but I'm sure will hit downstream consumers pretty quickly (eg: anyone doing automated nightly builds for their communities - that list is growing).

Comment 6

[Kevin Grandon :kgrandon]

Comment on attachment 8370508 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/15958

The white wrapper seems *really* bad and I have not seen that before. Do you see anything in logcat? If you can file a bug for that with device/build info it would be really appreciated. I will try to fix URL editing today/tomorrow.

Current bug list is located here: https://bugzilla.mozilla.org/show_bug.cgi?id=rocketbar-mvp

For the best possible product in 1.4, my recommendation would be to leave rocketbar enabled by default. As we can not enable both rocketbar *and* browser, I'm clearing the reviews here. The solution is to either fix rocketbar faster, or disable it by default for now.

Comment 7

[[:fabrice] Fabrice Desré]

Given what you have on your plate for 1.3, I guess we have to disable the rocketbar by default.

Comment 8

[Dietrich Ayala (:dietrich)]

(In reply to Fabrice Desré [:fabrice] from comment #7)
> Given what you have on your plate for 1.3, I guess we have to disable the
> rocketbar by default.

I don't understand why we can't have both during this transition.

Comment 9

[Dietrich Ayala (:dietrich)]

Sorry, last comment was meant to be a reply to Kevin :)

I'm all for getting Rocketbar rocking for 1.4! But it just seems not ready to wholly replace the browser by default given that (growing) list of open issues.

Comment 10

[Kevin Grandon :kgrandon]

We can't have both due to link activities and it breaking common workflows - we need to modify manifest files. (You can't just comment stuff out in the build step and have things just work). There may be a way around this, but we would need to think about it more - and I would rather spend that time just fixing the rocketbar :)

I would suggest to build with ROCKETBAR=0 make, but if that is not an option for any reason, we can disable by default.

Comment 11

[Kevin Grandon :kgrandon]

Attachment: disable_default_rocketbar.patch

I would rather not, but if we do anything we could do this.

Comment 12

[Jason Smith [:jsmith]]

Here's a summary of this from a QA perspective:

Summary of Opinion

1. We need to ensure quick resolution of the smoketest blocker & getting e.me UI automation back on with rocketbar on
** If this does not happen within a short period of time, then rocketbar should be preffed off by default again
2. Assuming [1] is met, daily smoketests & ui automation would be okay, so this would be safe to remain preffed on in trunk only.
** We also know the fully featured browser is accessible on production builds, so a workaround is available for testing if need be
** For special cases where we need the fully featured browser by default, QA could generate a build with the rocketbar pref disabled. The testers know how to do their own builds in Gaia, so this is possible to workaround.

Options

Leave rocketbar on by default on trunk only - for argument

Pros:

* UX gets the feedback they need from daily testers on the pain points of the feature - which has already been deemed as really important
* We get bake time on trunk with daily testers to reveal bugs via exploratory testing - which will be needed given the feature complexity

Cons:

* There's one smoketest blocker which requires people migrating to the rocketbar build to factory reset
* The e.me Gaia UI automation isn't running with this feature turned on
* The UX is still in significant flux on trunk, so we could risk basic workflow issues if something lands that revamps the UX that causes serious regressions by caveat

Pref off rocketbar by default

Pros:

* Unblocks testing by default using browser
* Keeps e.me UI automation running correctly

Cons:

* UX loses out on daily tester UX feedback
* Daily testing won't cover exploratory testing on the rocketbar

Here's the caveats of the tradeoffs here:

* This isn't a development blocker, given a build flag is present here to allow developers to use a fully featured browser
* The current quality state of rocketbar is too low to be uplifted when we branch, so we would pref off on an uplift if the quality state wasn't good enough

Comment 13

[Ben Francis [:benfrancis]]

I do think the Rocketbar was enabled by default prematurely, the implemented features do not match the UX spec and it doesn't fulfil all the use cases of the browser app yet. This means it makes the device difficult to use and bugs are being filed against unfinished functionality.

Arguably there is an advantage to having Rocketbar turned on by default to get early feedback, even if that feedback is on unfinished functionality. It also makes writing integration tests easier.

I do think it's possible to have both turned on, but with an inferior experience. You would see a web activity app selection box every time the View URL web activity is called so you can choose between the system app and the browser app. In the browser app you would also effectively have a URL bar inside a URL bar. Dietrich, how does that option sound to you?

Comment 14

[Dietrich Ayala (:dietrich)]

Sounds fine Ben, thanks! It'll be like using Android with multiple browsers ;)

Another question: When is the fake browser on the homescreen going away?

Comment 15

[Ben Francis [:benfrancis]]

(In reply to Dietrich Ayala (:dietrich) from comment #14)
> Another question: When is the fake browser on the homescreen going away?

The new browser icon isn't going away, for now we can have both but it will eventually replace the current browser icon.

Currently the new browser icon is just a homescreen bookmark for mozilla.org which opens up a system browser window (like very early versions of the browser app just loaded google.com). This isn't specified behaviour, but we're waiting on a UX spec for the new browser start page. The new browser icon will probably still be a bookmark, but to a special page like about:newtab which displays top sites and history etc.

Again, this was landed on by default in an incomplete state which is probably why it's confusing. Kevin is taking a look at reverting part of his patch to re-enable the browser app by default and have the old browser app co-exist with the system browser.

Comment 16

[Kevin Grandon :kgrandon]

Working on a solution now.

Comment 17

[Kevin Grandon :kgrandon]

Attachment: Github pull request

This implements three levels of configuration for the ROCKETBAR build flag.

none - No rocketbar, everything should be the same as 1.3.
full - Full rocketbar experience, browser app is removed.
half - Rocketbar is present along with the old browser app. Tapping on links will show an activity with two options, one for the Browser, and one for the System. This is the default option.

If you wanted to build with something other than the default, you could do:

```
ROCKETBAR=full make reset-gaia
```

Comment 18

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Kevin, we are refactoring build system and browser app related code snippet will be migrated to makefile and js build script in directory of browser app on bug 968668

can we fix this issue after bug 968668 landed? or this issue is more critical so we need to fix it now?

Comment 19

[Kevin Grandon :kgrandon]

So the browser code will be going away in the near future, and we will not need a Makefile. The code snippet is only used as a temporary workaround for 1.4.

Regarding priorities, Dietrich expressed concern that we do not have a browser app currently, and it may be valuable to have around for a bit longer by default. Are you worried about merge conflicts? Have you guys started working already?

Comment 20

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

I didn't realize browser will be going away in the near future when I made the refactoring plan :-/

George have a WIP patch for Browser Makefile file and js build script, but let's review and land your PR to get browser back first.

Comment 21

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Comment on attachment 8371465 [details] [review]
Github pull request

r=yurenju if nit is addressed.

Comment 22

[Kevin Grandon :kgrandon]

Thanks! Landed: https://github.com/mozilla-b2g/gaia/commit/b59f29dd88d0b68b19adf4f106df8d6fc3e1483e

Comment 23

[Robert Kaiser]

One thing I worry about with full rocketbar workflow is that removing the explicit browser app removes the always-visible Firefox logo from the launch screen, which sounds suboptimal branding-wise. Do we have some plans to bring the logo back in some way?

Comment 24

[Kevin Grandon :kgrandon]

(In reply to Robert Kaiser (:[e-mail]) from comment #23)
> One thing I worry about with full rocketbar workflow is that removing the
> explicit browser app removes the always-visible Firefox logo from the launch
> screen, which sounds suboptimal branding-wise. Do we have some plans to
> bring the logo back in some way?

I am sure that the current browser bookmark will be replaced with the normal browser icon, and will open more of a typical branding experience. This work is targeted for 1.4.