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)
Tracking
(Not tracked)
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:
Comment 1•12 years ago
|
||
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)
Comment 2•12 years ago
|
||
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)
Comment 3•12 years ago
|
||
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)
Updated•12 years ago
|
Whiteboard: [apps watch list]
Comment 4•12 years ago
|
||
QA, can you confirm if this is a problem for all external urls accessed from the Facebook app?
Keywords: qawanted
Comment 5•12 years ago
|
||
(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
Comment 6•12 years ago
|
||
(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)
Comment 7•12 years ago
|
||
(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)
Comment 8•12 years ago
|
||
(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)
Updated•12 years ago
|
Component: Gaia → Preinstalled B2G Apps
Product: Boot2Gecko → Tech Evangelism
Version: unspecified → Trunk
Comment 9•12 years ago
|
||
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)
Updated•12 years ago
|
Flags: needinfo?(jonas)
Comment 10•12 years ago
|
||
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)
Comment 12•12 years ago
|
||
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.
Updated•12 years ago
|
Blocks: b2g-facebook
Reporter | ||
Comment 13•12 years ago
|
||
I think point of comment#12 can not be ignored,please check it .Thank you.
Updated•12 years ago
|
Whiteboard: [apps watch list] → [apps watch list1]
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.
Comment 18•12 years ago
|
||
Harald, will you check this & respond regarding Comment #10?
Flags: needinfo?(hkirschner)
Comment 19•11 years ago
|
||
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.
Comment 21•11 years ago
|
||
(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.
Comment 23•11 years ago
|
||
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.
Assignee | ||
Comment 24•11 years ago
|
||
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)
Assignee | ||
Comment 25•11 years ago
|
||
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.
Assignee | ||
Comment 28•11 years ago
|
||
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.
Comment 29•11 years ago
|
||
Hi Harald, do you have the bug # for the new app chrome feature? thanks
Flags: needinfo?(hkirschner)
Assignee | ||
Comment 30•11 years ago
|
||
Facebook added "chrome" to their manifest, this fixes this bug for leo.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(hkirschner)
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•