the codebase has support for this feature however management squished it from
the release. tabbed browsing has nothing to do with Mozilla based browser for
maemo and is entirely the subject of the browser ui (a separate component).

as such, this bug isn't really valid.

If it weren't for the fact that people won't look for this bug where it
belongs, I'd move it to Browser or change its resolution.

I'd like tabs as well.  I have been accidentally closing the wrong windows
lately due to lag when I select them (when multiple browser windows are open). 
Tabs would help that for me.

they wouldn't. really. bugzilla is not for advocacy. it's for bugs. this isn't
a valid bug.

OK.. I realize this may be a bit much for you to understand, so I'm going to
type real slow.  The severity category for this was enhancement.  That means
that it is a request for additional features.(consult bugzilla's documentation
for further help in this area.)  Since this is the only mozilla related
category it's rather hard to file enhancement requests against other
applications.  I'm sorry you wasted my time.  

BTW if you don't want enhancement requests Then I highly recommend removing the
enhancement category and not asking people for feedback and enhancements. (as
was done in the announcement.

Comment 5 Andrew Flegg 2007-07-19 13:19:54 UTC

I understand the architectural point that it this is a browser-ui enhancement
request. However, I'd still like to see it.

The enhancement request *is* valid (possibly resolved as WONTFIX if there's no
chance of it ever being implemented), and so should be moved to the right
component and/or the resolution changed.

Comment 6 Andrew Flegg 2007-07-19 13:23:41 UTC

Reopening and moving to "Browser" component after discussion with timeless on
#maemo.

Comment 7 Tuomas Kuosmanen 2007-07-20 13:10:55 UTC

Hmm. Let me try to explain quickly (sorry, I am at Guadec right now, if someone
is here and wants to discuss it today, feel free to grab my sleeve :-))

In any case, the problem needs a bit more thinking than just "lets put tabs
there" - it relates to how the windows are managed etc. Tabbed browsing does
work wonderfully on the desktop computer where you have several different
application windows, and firefox neatly groups everything into one.

On the tablet, the screen is smaller, thus you wouldnt fit that many tabs, thus
imho the vertical window list works much better for this without stealing
precious screen estate.

This is not about "tabs are out of question due to management iron fist" (and I
dont think such comments help, lets try to avoid being kids, shall we? :)) but
rather one needs to look into the big picture of how we manage windows and
application switching on the device, and how tabs would fit into this scheme -
just copying the desktop UI directly would not work that well. It just needs a
good design that works better than what we currently have, to be worth the
hassle, in my opinion.

James, I havent tried minimo recently, what do you like best in the tabs? To
fix performance issues, the best thing would really be to try to fix the
performance issues instead of working around them in the ui.

indeed the vertical window list, accessed via the menu button in full screen
mode, provides equivalent functionality imho.  the actual use case I'm looking
for with tabs is to be able to open a link in the background, then switch to it
later after (1) I've finished reading the remainder of the current page and (2)
the new page has had time to load.

No tabs please.

This will end up confusing the end user when they see that almost every other
program's windows all show up in the taskbar except the web browser, where they
have to switch to the web browser and THEN again switch tabs in another part of
the screen to get to what they want. This goes against the standard UI and
expectations of end users on Maemo.

on a second thought, I agree. no tabs. taskbar switcher is enough. but add a
"open in new window in the background" option, with fullscreen shortcuts to
switch windows. (maybe on fullscreen mode make left and right arrows switch
windows, optionally)

Comment 11 Andrew Flegg 2007-07-20 16:58:38 UTC

Yes, it's not tabs per se which are the important things such:

* An ability to open links in the background easily (a long tap is too long and
is tricky when on a moving train/bus; perhaps holding down select & tapping?)

* An ability to quickly move from one open browser window to another (I think
Home -> Scroll/search -> tap is too long; I quite like the idea of left/right
buttons in the toolbar)

To add some additional useful thinking around the overall discussion on Mozilla
tabbed windows and/or (Hildon) Home + Select a currently open (named) browser
window etc.

I voted for tabs to be included because I use them regularly with additional
plugins which take advantage of tab window saving thus allowing me to quickly
return to saved sessions of opened and tabbed windows.  I currently use Session
Manager https://addons.mozilla.org/en-US/firefox/addon/2324

On a related note I also use Foxmarks Bookmark Synchroniser
https://addons.mozilla.org/en-US/firefox/addon/2410

I fully appreciate the discussion around "are tabs" the best way forward, but
PLEASE bare in mind that whatever we choose we need common hooks into mozilla
to take fullest advantage of plugins such as the ones above to make switching
between our Tablets and desktops and occasional PC's we do not own; a real
synchronised browsing pleasure :-)

To be able to access centrally saved/stored bookmarks and Mozzila sessions on
either our tablets and Desktops would be a really great feature IMHO.

Comment 13 Neil MacLeod 2007-07-21 16:29:38 UTC

I've been opening multiple windows in Maemo Mozilla browser over the last
couple of days, and these are my thoughts.

1. Opening multiple windows renders the Home menu unusable - each time the new
window is updated by the browser as the page loads, the Home menu is
automatically closed making it impossible to select another existing window.
This issue needs to be fixed (should I open a new bug?) before the Home menu
can be considered a serious alternative to tabs

2. D-pad center currently has no function in Maemo Mozilla Browser - did it do
anything in Opera? I suggest we use D-pad center + stylus click on a link to
open the link in a new window (or tab, according to preference)

My preference would still be for tabs, as I believe Minimo has shown that tabs
don't take up too much space, can be accessed without having to press the Home
menu button, and can be opened in the background to be read later once they
have loaded (new windows currently take focus which isn't what I want, and mess
up the Home menu).

My typical use case for tabs is to go to a news or forum web site, open several
links that interest me in seperate tabs then view the pages in sequence often
starting with the first tab while the last tab is yet to finish loading.

I think it's fair to say that I don't think anyone is asking for tabs to be
added in the next beta or full release, just that tabs be considered for
inclusion at some point in the future as a user selectable alternative to
seperate windows.

Neil, #1 happens with Opera too, but that doesn't render the Home menu useless
whatsoever unless you spend far more time loading pages than reading them.

While I don't think tabs are a good idea on small screen sizes, I think we
stumbled upon something most people do seem to want: opening links in a
background window.

Comment 15 Neil MacLeod 2007-07-22 04:28:46 UTC

(In reply to comment #14)
> Neil, #1 happens with Opera too, but that doesn't render the Home menu useless
> whatsoever unless you spend far more time loading pages than reading them.
> 

Correct, it's not a bug particular to Mozilla engine but rather the Browser UI,
which is shared with Opera also. And it could well be a problem with other apps
too if it's a core bug rather than an application level bug. I really don't
know  enough to say where the problem lies.

What is for sure is that the Home menu is not a useable task/window switcher
whenever a (browser) window is actively updating it's own contents
(specifically the window title which needs to appear in the Home menu).

When a browser page takes several seconds to load (sometimes as long as 30+
seconds with over 100+ items according to the progress bar when I _really_
became aware of this bug the other night) it's simply not possible to switch to
another window window via the Home menu because the Home menu closes itself as
the browser window content is updated.

Only when the browser window has finished loading will the Home menu remain
open. Try it! :)

One of the points in favor of 'tabbed browsin'...

"3) It would add stability to the browser:
Although the browser on my n800, of course. never crashes, it could one day do
so theoretically 
In that case our browser will be able to remember all of its children=tabs and
offer to restore them the next time we open the browser. as happens now in
firefox and maxthon. I believe that to be a very important feature."

...that I made in this posting to the internettablet forum:
http://www.internettablettalk.com/forums/showthread.php?p=62422#post62422

I'd like to see tabbed browsing as well, if not in the original Opera-based
browser then in the newly released Mozilla browser currently undergoing alpha
testing.

(In reply to comment #16)
> One of the points in favor of 'tabbed browsin'...
> 
> "3) It would add stability to the browser:
> Although the browser on my n800, of course. never crashes, it could one day do
> so theoretically 
> In that case our browser will be able to remember all of its children=tabs and
> offer to restore them the next time we open the browser. as happens now in
> firefox and maxthon. I believe that to be a very important feature."
> 
> ...that I made in this posting to the internettablet forum:
> http://www.internettablettalk.com/forums/showthread.php?p=62422#post62422
> 

And like I said in my post afterwards, adding tabs does not add any sort of
stability alone so this point is completely moot.

Comment 19 Quim Gil 2008-07-21 07:57:18 UTC

Hi, this report appears in the Jar Bug top 10. Any updates?

1. tabs rely on systems having lots of memory and were a solution to a problem
that doesn't exist on our device: slow window creation times.
a. having used windows on devices with very little memory, running out of
memory is bad (and in case you're curious, running out of memory on Linux
devices is worse)
b. having used windows on devices with very little memory, crashing is bad
c. having used browsers on devices with very constricted cpu power, crawling is
bad
2. people should look at the current plans for fennec, there's a nice video
about it ... http://azarask.in/blog/post/firefox-mobile-concept-video/
please note that tabs aren't really on the table.
3. (comment 8) we currently have open link in new window, but that steals
focus. i'm willing to try to work w/ people on changing that one. i don't think
there's much benefit in showing an empty window right away.
4. (comment 12) we're not using xul for any of our ui, which means that there
are no integration points and asking for them is not going to get you anywhere.
5. (comment 13 #1) if the window manager was broken you should have filed a
bug, what was the bug number? for reference, file manager will change its title
if you have a mmc selected and remove the mmc. this seems to be the best
equivalent for testing a background change. in testing the bug described here
does not seem to exist in diablo (and probably went away w/ chinook).
6. (comment 13 #2) this is not the forum for asking how the browser works. the
dpad button is equivalent to <click> or <enter> and it will let you open a link
w/o tapping the screen, select a radio, toggle a checkbox, toggle the selection
of a listitem, sometimes it may open the finger keyboard for text widgets, and
it may submit forms. it's expected to be similar to pressing <enter> on a
normal desktop browser, changing its behavior is pretty much out of the
question.

here's a proposal in steps:
1. "Open link in new window" is renamed to "Open link in background"
2. when a page is opened in the background, it is given a timer (tentatively 2
mins - i will not object to this timer's limit being pref controlled)
3. when the page finishes loading
a. the timer is cleared
b. we use the system notification that you get for chats/emails to tell you
that the page is loaded
i. the icon for the item is a preview of the page's screen.
assuming we have two lines for text
ii. they're dedicated to "Ready: {pagetitle}" or "Done - {pagetitle}"
iii. with a second line probably the time that you /opened/ the link (not the
time when the page finished loading, my goal is to remind you when you asked
for the page).
iv. clicking the item will bring the window to the front.
4. if the timer fires then that means the page didn't finish loading in a
reasonable time period and we should tell the user that and remind them that
they have this window that is still loading.
a. we clear the timer (it's actually ONE_SHOT, but I'm noting that you'll only
get one of these messages)
b. we fire an information thing
i. with the current preview and an overlay of a red clock
ii. first line title of "Overdue: {pagetitle|url}" or "Still Loading -
{pagetitle|url}"
iii. time from when you opened the link as in 3biii
5. as for alternate ways to open links in background, typically ctrl-click
should work. i'm not opposed to this.
6. I think that for the n800 you're going to be stuck using the CSM. Personally
if I were allowed to violate ui conventions, i'd set up the menu key to act as
a mouse modifier so that onkeydown it's a modifier (meaning "right-click") and
if you click we'd trigger a right click, if you didn't click before onkeyup
then onkeypress is fired as the normal show system menu event. But I'm sure I
won't be able to get that.

It'd be enough for me to open the window in the background, with no timers or
added complications. I'd actually hate a notification while I'm reading another
page.

Comment 23 Andrew Flegg 2008-07-29 00:01:36 UTC

> It'd be enough for me to open the window in the background,
> with no timers or added complications.

Agreed, I'm not going to forget I opened a window; and the notification won't
help me navigate to the loaded page (unless it's some abomination of a modal
dialogue box </shudder>).

My typical use case would be opening a series of links and then working my way
through them, closing windows as I went.

Comment 24 Andre Klapper 2008-08-12 21:40:04 UTC

*** Bug 3559 has been marked as a duplicate of this bug. ***

Comment 25 Eero Tamminen 2008-08-13 15:44:55 UTC

I think bug 3557 would make this feature fairly useless, so adding it as
a dependency.

(and personally I wouldn't want any timers/notifications either, just
an ability to open windows/tabs in background.  For me CMS menu item
would be OK for that.)

Comment 26 Roope Rainisto 2008-11-24 20:44:18 UTC

I'd like to move _THIS_ bug to the UI specifications...

Comment 27 Roope Rainisto 2008-11-24 20:47:19 UTC

Fremantle will provide an improved UI experience related to handling and
presenting multiple browser windows, so yes, assigned. (Although no, don't
expect to see tabs 100% like in your desktop browser).

Comment 28 Quim Gil 2008-11-26 13:07:08 UTC

Fixed in Fremantle

Comment 29 Andre Klapper 2009-10-01 19:25:51 UTC

Sorry, but I still fail to see how this specific request, opening a link in the
background, is FIXED in the Fremantle browser.
If there is a way to do this then I'm too stupid to find out.
Reopening.

fremantle has live window previews, kinda like fennec tabs. it didn't get open
in background which has kinda bothered me of late.

Comment 31 Quim Gil 2009-10-02 07:30:05 UTC

One problem here is that the initial subject talks about 

Provide "open link in background"

This is indeed not fulfilled in Fremantle.

But then the whole discussion has been around tabs, and Roope said "Fremantle
will provide an improved UI experience related to handling and
presenting multiple browser windows"

This is the Maemo 5 dashboard, that at that time we could not disclose. It
makes it easy to jump between browser windows and any other app you have open.

Assuming that you are happy with the tab functionality being provided through
the dashboard (allowing you to have cleaner browser pages running actually at
fullscreen by default = no browser UI at all), then the case for "opn link in
background" is less glamorous. We are talking simply about an additional option
in the context menu when you press longer a link.

Is this what we are talking about, then? If so we didn't need the +20 messages
about tabs.  :)

A question out of curiousity: is Fennec providing this "open link in
background" functionality nowadays? I don't have it installed. It's good to
know what mother Mozilla thinks about this.

IF one uses eg. Google Reader this functionality is a must.
An not even by long press, but rather something taking less time eg.
CTRL+press.
It's normal that while reading one wants to follow some links for further
reading without leaving currently read article.

Comment 33 Quim Gil 2009-10-14 09:41:28 UTC

Under study.

Comment 34 Andre Klapper 2009-11-05 13:40:32 UTC

*** Bug 6041 has been marked as a duplicate of this bug. ***

Comment 35 Andre Klapper 2009-11-28 02:06:31 UTC

*** Bug 6366 has been marked as a duplicate of this bug. ***

A key combo to quickly switch back to the previous window may help.

Comment 37 Tim Samoff 2009-12-24 16:16:56 UTC

(In reply to comment #36)
> A key combo to quickly switch back to the previous window may help.
> 

Actually, I've often wished for something akin to Alt+Tab (Fnc+Shft+Backspace?)
in Maemo 5. But, that would be more of a Brainstorm entry than a Bugzilla
Enhancement entry.

There's also something like this at Brainstorm:
http://maemo.org/community/brainstorm/view/placement_of_the_task_switcher_at_the_bottom_of_the_screen/

Solution #4 may help you. Added 3 Month after the beginning of the election.
But if the Idea is good enought it could win the fight. ;-)

Press STRG+Backspace twice to get the same like alt Tab. In my opinion a good
and easy working solution.

Please continue this discussion here:
http://talk.maemo.org/showthread.php?t=37745 or open a new Brainstorm. :-)

*** Bug 8239 has been marked as a duplicate of this bug. ***

Comment 40 Quim Gil 2010-01-25 08:21:48 UTC

The plan is to implement this enhancement request in a Maemo 5 update. Setting
target milestone accordingly.

Okay, for all interested voters:

There is a workaround we can use during waiting for the fix. (only for the
N900)

I guess the most of us will like it. It doesn't give the users a "open link in
background", but a fast way to switch back to the browser page you come form.

You have to replace your hildon desktop with a modified one. You can find it
here:
http://talk.maemo.org/showpost.php?p=482980&postcount=20

Please read also the rest of the Thread carefully. Be aware: You're downloading
here a essential part of the system from a unofficial repository and website.
Everything could happen! A bricked device, maleware, spyware and your N900 can
get alive and bite you in the night! Test it at your own risk!

If you like the usability you can vote at this Brainstorm:
http://maemo.org/community/brainstorm/view/shortcut_to_switch_between_running_applications/


This was the first part. Now you can switch from one to the other application
(very simmilar to Alt-Tab) with only two presses of CTRL+BACKSPACE

If you want to keep the Keyboard closed use the programm ShortCutD. You can
find it at the moment in Extras-Testing. Here you can collect more
informations: http://talk.maemo.org/showthread.php?p=495687

Now you can click on "Open link in new window" and then just press the camera
button twice and you're back at your page. It's very fast and you'll get also
at the email client a "open link in background". (I love it)

I know, this is not a forum. Sorry for the Noise. But I hope this could help
many of the 71 Voters. :-)

I'm not sure how this bug got hijacked, but this was about opening links in the
background.  I consider the lack of this feature a bug because its absence
causes unnecessary battery drain for what is a reasonable and popular use case.
 That's not much of a stretch, is it?  :)

i'm giving this bug to quim. afaict the request was for a menu item. it looks
like internal progress has resulted in a specification for /something/ but the
implementation's approval got stalled. since this requires badgering, it falls
to quim.

Comment 44 Andre Klapper 2010-03-02 18:23:38 UTC

(Fixed in the internal UI Specification, code implementation nearly done.)

Comment 45 Andre Klapper 2010-03-11 15:21:40 UTC

(Removing unrequired and misleading dependency bug.)

*** Bug 9639 has been marked as a duplicate of this bug. ***

May I ask the status for this bug? It's not added in 2010.36-2. Will it be
released some time later or has the enhancement been dropped already?

If everyone asked in every bug that would be bad. Bugs are to track progress,
lack of progress is obvious by silence. So please don't take this as me
encouraging the practice.

Management decided it wasn't important enough for the next release.

Complaints can be directed via Nokia Care. Management was informed that there
were 104 votes (there have been an additional 7 votes since then...).

Thanks timeless for the very helpful, I understand what you mean. Just want to
make sure because from earlier bug comment I thought this would be in for
PR1.3.

It's been almost a year since last comment, I hope I don't cause a problem by
asking - is there any progress with this issue? If you could point me somewhere
where I could read some info It would be great. Thank you a lot and sorry for
"discussing" here.

Comment 51 Andre Klapper 2011-09-30 12:44:55 UTC

The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries) are
considered stable by Nokia. Only critical issues have a chance of being
addressed by Nokia. Note that there are plans for community software updates
for those components that are open-source. The browser user interface is not,
as far as I know.

Why don't we change the status to WON'T FIX?

Comment 53 Andre Klapper 2012-02-21 11:32:19 UTC

Yeah. Problem is that the internally tested patch was never shipped to end
users as it did not work reliably. 
Plus as this part of the browser is closed source there won't be much more
happening either by any party.