Closed Bug 881425 Opened 12 years ago Closed 8 years ago

The hardcoded back button misbehaves on articles

Categories

(support.mozilla.org :: Mobile, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: ibai, Unassigned)

Details

(Whiteboard: u=user c=mobile p=1 s=2013.backlog)

Whenever an article is accessed from mobile, after having navigated from support.mozilla.org the back button (not the one on the browser but the one of the site) has a bug. Actual behavior: 1- Navigate to support.mozilla.org 2- Click on a product 3- Click on a topic 4- Click on an article 5- Click on the back button 6- This click brings you to Learn the Basics, regardless of the topic that you were before. Expected behavior: 1- Navigate to support.mozilla.org 2- Click on a product 3- Click on a topic 4- Click on an article 5- Click on the back button 6- You land in the topic that you selected in step 3. This is an important thing to fix before the launch.
Should be easy enough to fix. Putting in next sprint.
Whiteboard: u=user c=mobile p=1 s=2013.12
Target Milestone: --- → 2013Q2
We'll revisit this once we are done with the IA changes and determine what makes sense. For now we will remove the button in bug 881906.
Whiteboard: u=user c=mobile p=1 s=2013.12 → u=user c=mobile p=1 s=2013.backlog
The back button on the top is a common metaphor for "one level up" on iOS and Firefox OS. Since we moved to a strict hierarchy we should be able to pull this off on the topic/subtopic and articles pages, right? The current work around works on topic and subtopic pages, but is uncommon and takes precious vertical space. Putting into next sprint, tentatively.
Priority: P1 → P3
Whiteboard: u=user c=mobile p=1 s=2013.backlog → u=user c=mobile p=1 s=2013.15
Target Milestone: 2013Q2 → 2013Q3
Kadir, the metaphor works great when it's an standalone app. When viewed in the context of a web browser it looks like a duplication back button next to each other. In addition, articles can still belong to multiple topics/subtopics...so I'm not sure if we are in a position for a good solution at the article level. It requires some thinking.
(In reply to Ibai Garcia [:ibai] from comment #4) > It requires some thinking. Based on that, moving to backlog.
Whiteboard: u=user c=mobile p=1 s=2013.15 → u=user c=mobile p=1 s=2013.backlog
Q3 is over... => Q4
Target Milestone: 2013Q3 → 2013Q4
Moving 2013Q4 bugs to the Future since we didnt care enough about them in 2014Q1.
Target Milestone: 2013Q4 → Future
unable to reproduce. closing.
Status: NEW → RESOLVED
Closed: 8 years ago
Priority: P3 → --
Resolution: --- → INCOMPLETE
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.