Closed Bug 735749 Opened 8 years ago Closed 8 years ago

No back button in awesomescreen on Maemo 6 Harmattan (N9)


(Firefox for Android Graveyard :: General, defect)

Firefox 9
Not set


(firefox12 fixed, firefox13 fixed, firefox-esr10- wontfix)

Firefox 14
Tracking Status
firefox12 --- fixed
firefox13 --- fixed
firefox-esr10 - wontfix


(Reporter: my_name_24, Assigned: mbrubeck)



(Keywords: regression)


(1 file, 1 obsolete file)

There is no back button for firefox for N9 when entering a web in the status bar and the only way to go back is to click on a web and close the tab .
Unfortunately, Firefox is no more supported for MeeGo.
Closed: 8 years ago
Resolution: --- → WONTFIX
There is a non obvious way to go back from the bookmarks All Pages, Bookmarks, History etc. UI. in the Harmattan XUL build. Just tap on the thin area right above the address bar. It should take you back to the previous screen.

In general, please don't mark these bugs as WONTFIX until you know for sure that this change is rejected out real reasons. Linux XUL builds aren't officially supported, but community still works on them.
There's a button here to return from the urlbar:

But it is hidden by default and shown only on Maemo, but *not* on Maemo 6 (Harmattan):

The best fix might be to change that line to "%ifndef ANDROID" should show the button on all non-Android platforms...
Ever confirmed: true
Resolution: WONTFIX → ---
Whiteboard: [][lang=xul]
Attached patch patch (obsolete) — Splinter Review
I don't have a Harmattan device to test this patch.
Assignee: nobody → mbrubeck
Attachment #610922 - Flags: review?(romaxa)
Summary: no back button in status bar → No back button in awesomescreen on Maemo 6 Harmattan (N9)
Whiteboard: [][lang=xul]
I tested the patch - it adds the close button which closes the browser which you tap it. The problem was not to close it, but to return back to the previous screen though.
Comment on attachment 610922 [details] [diff] [review]

Oh right, I'm getting my toolbar buttons mixed up.  Sorry.

There's a button to close the preferences panel on Maemo, but there doesn't seem to be any similar button to close the awesomescreen.  How was this handled on previous Maemo versions?
Attachment #610922 - Flags: review?(romaxa)
(In reply to Shmerl from comment #5)
> I tested the patch - it adds the close button which closes the browser which
> you tap it. The problem was not to close it, but to return back to the
> previous screen though.

Actually, it *should* return to the previous screen if you tap the button while the awesomescreen (All Pages / Bookmarks / History screen) is visible.

Perhaps on Maemo 6, Fennec should display the button only when the awesomescreen is visible, and hide it otherwise.
Well, in my case it just closes the browser. It doesn't return to the previous screen. I did a dirty hack test, just updates the browser.css inside the jar file adding this line:

#toolbar-main[fullscreen="true"] #tool-app-close {   visibility: visible; }

Anyway, adding more buttons in such a narrow space isn't a good design approach.

Current method (taping on the small area above the address bar) works, but it's very not intuitive and non obvious. I noticed that long tap on the address bar brings out a context menu with "Paste" and "Paste & Go" entries. May be the "Back" entry can be placed there?
Assignee: mbrubeck → nobody
Whiteboard: [][lang=js][lang=xul]
Attached patch patch v2Splinter Review
This was a regression from bug 680212.  The changes to the AwesomeScreen.activePanel setter made it pass "null" to BrowserUI.pushDialog.  This had no effect on Android, but on desktop and Maemo it breaks the showing of #tool-app-close button.

Bug 680212 also added a TapDown handler that closes the awesomescreen on TapDown "outside" of it.  When clicking on the close button, the awesomescreen would close in the TapDown handler, and then the button click would cause the app to quit (which explains the problem in comment 5).  This patch adds a line to make the close button be considered "inside" the awesomescreen.
Assignee: nobody → mbrubeck
Attachment #610922 - Attachment is obsolete: true
Attachment #610947 - Flags: review?(mark.finkle)
Note: I tested this patch on Android (including in tablet mode) as well as on desktop (which matches the Maemo behavior and styles).
Blocks: 680212
Keywords: regression
Whiteboard: [][lang=js][lang=xul]
Version: Firefox 11 → Firefox 9
Attachment #610947 - Flags: review?(mark.finkle) → review+
romaxa, should I ask for this to be backported to beta/aurora for Fx12/13?  Or perhaps you can just include it as a local patch in your Ovi store builds until it reaches release.
Target Milestone: --- → Firefox 14
Let me check first, how it works on nightly build. Yep, it would be nice to backport it to sooner release after I test it. (don't like to keep patches for ovi builds)
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Comment on attachment 610947 [details] [diff] [review]
patch v2

[Approval Request Comment]
Regression caused by (bug #): bug 680212

User impact if declined: No discoverable way to exit the awesomescreen on Maemo.

Testing completed (on m-c, etc.): Landed on m-c about a week ago.

Risk to taking this patch (and alternatives if risky): This is a low-risk, 2-line patch that only touches XUL Fennec.  It has no visible effect on Android.  It's needed only for Firefox for Maemo/MeeGo, which is available to users through the Ovi Store.

String changes made by this patch: None.
Attachment #610947 - Flags: approval-mozilla-beta?
Attachment #610947 - Flags: approval-mozilla-aurora?
Comment on attachment 610947 [details] [diff] [review]
patch v2

[Triage Comment]
Approved for Aurora 13 and Beta 12. Presumably we need this fix on the ESR too, so approving for that branch as well.
Attachment #610947 - Flags: approval-mozilla-esr10+
Attachment #610947 - Flags: approval-mozilla-beta?
Attachment #610947 - Flags: approval-mozilla-beta+
Attachment #610947 - Flags: approval-mozilla-aurora?
Attachment #610947 - Flags: approval-mozilla-aurora+

I don't think anyone is producing esr10 builds for Maemo or MeeGo, so I don't think there's any reason to land this patch there...
Marking as "wontfix" for esr10, unless someone knows a reason to change that.
You need to log in before you can comment on or make changes to this bug.