Closed Bug 856567 Opened 12 years ago Closed 11 years ago

[Buri][Facebook]There are no Forward and Backward softkey when using Facebook

Categories

(Tech Evangelism Graveyard :: Preinstalled B2G Apps, defect, P2)

Product:
Tech Evangelism Graveyard
Component:
Preinstalled B2G Apps
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: sync-1, Assigned: Harald)

References

Details

(Whiteboard: [apps watch list1]) 

+++ This bug was initially created as a clone of Bug #429632 +++
 
 SW115
 AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.19.044
 Firefox os  v1.0.1
 Mozilla build ID: 20130319070203
 
 DEFECT DESCRIPTION:
 [Facebook]There are no Forward and Backward softkey when using Facebook.
 
 REPRODUCING PROCEDURES:
 1.connect to phone-wifi2
 2.click Facebook icon,and log in
 3.when using Facebook, when goto some page, cannot go back to previous page;there are no forward softkey and backward key, it makes bad user experience---KO
 
 EXPECTED BEHAVIOUR:
 As there is only one home key on Bettle lite FF, when using app facebook, it should supply softkey for user to forward and backward.
 
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 
 REPRODUCING RATE:5/5
 
 For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #429632 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
blocking-b2g: --- → tef?
We are using window.open for opening those URLs and it seems no navigation bar is offered in that case. Josh, is this intentional?
Flags: needinfo?(jcarpenter)
It sounds like this is an instance of navigating to an external URL while using Facebook?

(In reply to Daniel Coloma:dcoloma from comment #1)
> We are using window.open for opening those URLs and it seems no navigation
> bar is offered in that case. Josh, is this intentional?

Yes, for v1, but going forward we want to upgrade our window.open to include back button (perhaps refresh also). Adding this for UX tracking. I don't think we'll be able to land this for 1.0.1 or 1.1, however. Daniel, do you see that as a major issue?
Flags: needinfo?(jcarpenter)
I think it would be good to have this feature, but at this stage this seems like a new feature request for 1.0.1. Based on that I am marking this as tef-. 

CCing Mozilla product team just in case they have a different view.
blocking-b2g: tef? → ---
Flags: needinfo?(ffos-product)
Whiteboard: [apps watch list]
QA, can you confirm if this is a problem for all external urls accessed from the Facebook app?
Keywords: qawanted
(In reply to Peter Dolanjski [:pdol] from comment #4)
> QA, can you confirm if this is a problem for all external urls accessed from
> the Facebook app?

It isn't going to be every single URL. The way apps work with URLs is the following:

- If it's a URL with a target blank identifier, we fire a web activity over to the browser to open the URL in the browser in a new tab
- If it's a URL without a target blank identifier, we open the content within the current app

We are doing the right behavior here. If the app developer tries to open everything within web content, then that's there fault - that's frowned upon in designing an app generally, as the concept of an app operates within an origin.
Keywords: qawanted
(In reply to Josh Carpenter [:jcarpenter] from comment #2)
> It sounds like this is an instance of navigating to an external URL while
> using Facebook?
> 
> (In reply to Daniel Coloma:dcoloma from comment #1)
> > We are using window.open for opening those URLs and it seems no navigation
> > bar is offered in that case. Josh, is this intentional?
> 
> Yes, for v1, but going forward we want to upgrade our window.open to include
> back button (perhaps refresh also). Adding this for UX tracking. I don't
> think we'll be able to land this for 1.0.1 or 1.1, however. Daniel, do you
> see that as a major issue?

This isn't a critical feature in app design and may actually be a bad idea to include this. We want app developers designing apps that operate within the origin primarily and only step off the origin for a temporary use case, such as logging into google, facebook, etc. But setting up the precedent that off-origin content is navigable like the browser violates the very definition of what makes an app - which on desktop, resulted in this style of bug getting a WONTFIX. In that argument, I'm arguing for a WONTFIX here, but I'm putting needinfo on you for a response here before I do that.
Flags: needinfo?(ffos-product) → needinfo?(jcarpenter)
(In reply to Jason Smith [:jsmith] from comment #6)
> (In reply to Josh Carpenter [:jcarpenter] from comment #2)
> > It sounds like this is an instance of navigating to an external URL while
> > using Facebook?
> > 
> > (In reply to Daniel Coloma:dcoloma from comment #1)
> > > We are using window.open for opening those URLs and it seems no navigation
> > > bar is offered in that case. Josh, is this intentional?
> > 
> > Yes, for v1, but going forward we want to upgrade our window.open to include
> > back button (perhaps refresh also). Adding this for UX tracking. I don't
> > think we'll be able to land this for 1.0.1 or 1.1, however. Daniel, do you
> > see that as a major issue?
> 
> This isn't a critical feature in app design and may actually be a bad idea
> to include this. We want app developers designing apps that operate within
> the origin primarily and only step off the origin for a temporary use case,
> such as logging into google, facebook, etc. But setting up the precedent
> that off-origin content is navigable like the browser violates the very
> definition of what makes an app - which on desktop, resulted in this style
> of bug getting a WONTFIX. In that argument, I'm arguing for a WONTFIX here,
> but I'm putting needinfo on you for a response here before I do that.

Navigating to off-origin content within a browser window is a common mobile app use case. See Twitter, Facebook, RSS readers, etc. I see what you're saying about it being a mixture of content-consumption models (browser vs stand-alone app) but it's really quite common in the world of mobile, and it works.
Flags: needinfo?(jcarpenter)
(In reply to Josh Carpenter [:jcarpenter] from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #6)
> > (In reply to Josh Carpenter [:jcarpenter] from comment #2)
> > > It sounds like this is an instance of navigating to an external URL while
> > > using Facebook?
> > > 
> > > (In reply to Daniel Coloma:dcoloma from comment #1)
> > > > We are using window.open for opening those URLs and it seems no navigation
> > > > bar is offered in that case. Josh, is this intentional?
> > > 
> > > Yes, for v1, but going forward we want to upgrade our window.open to include
> > > back button (perhaps refresh also). Adding this for UX tracking. I don't
> > > think we'll be able to land this for 1.0.1 or 1.1, however. Daniel, do you
> > > see that as a major issue?
> > 
> > This isn't a critical feature in app design and may actually be a bad idea
> > to include this. We want app developers designing apps that operate within
> > the origin primarily and only step off the origin for a temporary use case,
> > such as logging into google, facebook, etc. But setting up the precedent
> > that off-origin content is navigable like the browser violates the very
> > definition of what makes an app - which on desktop, resulted in this style
> > of bug getting a WONTFIX. In that argument, I'm arguing for a WONTFIX here,
> > but I'm putting needinfo on you for a response here before I do that.
> 
> Navigating to off-origin content within a browser window is a common mobile
> app use case. See Twitter, Facebook, RSS readers, etc. I see what you're
> saying about it being a mixture of content-consumption models (browser vs
> stand-alone app) but it's really quite common in the world of mobile, and it
> works.

In a browser window, that's true. But we're talking about app content here. I'm concerned that introducing say, the wrapper UI during a pop-up off-origin flow could potentially start pulling content off the origin primarily in app development, even though we want content within the app to be implemented on origin.

Jonas - What's your stance here?
Flags: needinfo?(jonas)
Component: Gaia → Preinstalled B2G Apps
Product: Boot2Gecko → Tech Evangelism
Version: unspecified → Trunk
This is a fix we need to the app developer to make.  We can make stop-gap solutions, but those will offer users a subpar experience which isn't something we can afford. 

Lawrence, do you have an update on where we are with this request?
Flags: needinfo?(lmandel)
Flags: needinfo?(jonas)
When Facebook is run in the browser of via E.me the back button exists. As such, this issue is specific to the Facebook app. Over to Harald, who manages the technical relationship with Facebook.
Assignee: nobody → hkirschner
Flags: needinfo?(lmandel)
Hi,I want to the status with this bug.
Is it possible to add the similar bottom bar as E.me in the Facebook APP? In current status, the facebook app is really hard to use. 

For example, before login, if user types the "Help Center" icon, then it is not possible go back to Facebook login screen.  He has to kill the APP and launch again.
I think point of comment#12  can not be ignored,please check it .Thank you.
Hi,how about this bug?Facebook is too hard to use.
Whiteboard: [apps watch list] → [apps watch list1]
Hi,how about this bug?
I think it'd be good to add both an argument to window.open, as well as to the application manifest, which indicates that an app wants to get forward/back buttons displayed.
But to be clear, that's not something that we can do for the v1.0.1 release. Much too late for that.
Harald, will you check this & respond regarding Comment #10?
Flags: needinfo?(hkirschner)
It seems people are talking about two separate issues here:

1. Links to external web sites which use the window.open UI instead of opening in the browser which has a back button.
2. Navigating around Facebook itself.

Number 1 is a wider issue which isn't unique to Facebook.

Number 2 is a fundamental part of Facebook's UI design in that it relies on a system back button, this makes the Facebook app in the Marketplace very difficult to use in Firefox OS which doesn't have one. Facebook briefly seemed to experiment with modifying their UI to add back buttons all over the place, but this change seems to have disappeared.

This is a major issue for the Facebook app which I hope Facebook are aware of.
It would be very helpful for application authors if they could declare in the app manifest that they want back/forward buttons to be enabled in the app-runner UI. That would probably significantly ease the adoption of our app platform by developers.

Ben, how doable is that in FirefoxOS? I imagine it'd involve some hackery in the system app.
(In reply to Jonas Sicking (:sicking) from comment #20)
> It would be very helpful for application authors if they could declare in
> the app manifest that they want back/forward buttons to be enabled in the
> app-runner UI. That would probably significantly ease the adoption of our
> app platform by developers.

It does ease the move of a website to a hosted web app. But it also introduces a crutch that I would expect partners would not allow in app design for high profile apps since this goes against content consumption model that apps are supposed to follow. The developer holds the responsibility of designing the app that can act independently of any crutches the system provides. Otherwise, the app model created here is just reinventing what everything.me has already created, which is set of mobile sites everything.me picked for their apps with a navigation bar provided.
Even if it's not acceptable for high-profile apps, I would expect it to be acceptable by many other developers. And it might be acceptable as a temporary workaround for high-profile apps.

FWIW, I believe other webapp platforms, like Windows 8, have built-in back buttons in the UI. Though I'm not sure that's the case.

ChromeOS hosted apps definitely do, but they run completely inside of a browser-UI, so I'm not sure that we'd consider those apps.
Whiteboard: [apps watch list1] → [apps watch list1] [3rd Party]
Issue repros on
Leo Build ID: 20130620160852
Gecko: /rev/
Gaia: ef85283d8a041cecf9a37348cf6a0b580804f3d6
Platform Version: 18.1

There is no back button when going to different pages on device such as Events, Groups, and Find Friends.  However it does work in other areas such as Your personal profile, when you click on a message, Help Center, and Settings & Privacy.
Got in touch with Facebook and hope to get some feedback from their product people.

Does anybody have a detailed list of dead ends? It seems very similar to the Youtube experience. User can't get stuck, just can't get "back". They still can use the main menu to get around and with more clicks even back where they came from. Are there cases where there is no menu, except external websites opening badly?
Flags: needinfo?(hkirschner)
FB did actually add a back button, which is currently depending on a flaky feature detection that I am working on with FB to fix.
Whiteboard: [apps watch list1] [3rd Party] → [apps watch list1]
Depends on: 895826
Depends on: 898977
@Harald: is there any update on the feature detection issue?
The button is shown, but its only one part of the solution. The fix depends on new app chrome feature which lands in 1.1.
Hi Harald, do you have the bug # for the new app chrome feature? thanks
Flags: needinfo?(hkirschner)
Facebook added "chrome" to their manifest, this fixes this bug for leo.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(hkirschner)
Resolution: --- → FIXED
Blocks: 916311
No longer blocks: 916311
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.