User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Build Identifier: firefox WinCE build for 8th July if I close all the tabs i.e. only one tab is kept open then the open a new tab button doesn't show. With 19th June build if the open a new tab button used to appear even if only one tab was kept open. I don't know this is regression or a new feature Reproducible: Always Steps to Reproduce: 1.intall and run firefox 2.close all tabs and keep only one tab open 3. Actual Results: "Open a new tab" button is missing. Expected Results: I don't know if this is new feature or a regression
Can you reproduce with a new profile? This is the third bug I've come across from you that started with the july 8th build so I'm pretty sure you have a corrupt profile or some extension is causing some serious problems.
Yeah, we hide the tab bar by default just to save some vertical space; a new tab can be created from the File menu, though having the button in the tab bar is more desirable. It's an UI issue, working with Alex to figure out what the right thing is to present to both save space but still have tabs accessible. An easy fix would be to put a new tab button on the toolbar, but that's somewhat ugly...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Alex, any thoughts on what we should do here? We hide the tab strip by default, maybe we just want to leave tabs as an "Advanced User" feature on these devices? They should be able to get to it with Control-T or the menu bar. Or, we can just put the new tab button in the toolbar, but I'd almost rather not do that.
Priority: -- → P2
I'm not entirely sure we ultimately want to hide the tabstrip by default, saving screen space is good, but the tabstrip on a small device like this is kind of like the new taskbar or dock (especially since the user is unlikely to have a lot of other Windows CE apps to install). Keeping the ability to create new tabs hidden until we can remove other parts of the UI (like the menu bar) is fine in the meantime though.
Related: If we put the tabstrip back in by default, we'll want to take the throbber out of the navigation toolbox (so we don't forget)
Note that we shipped Firefox 3.0 with tabstrip auto-hiding and no new-tab button in the default setup, so I think that should be acceptable here as well. Of course it depends on how high you value the vertical space. If we're talking about 600px, then based on my netbook usage, I'd say there's room for the tabstrip.
Created attachment 388744 [details] [diff] [review] Patch v0.1 Since this is Firefox specific, I just set it in firefox.js, overriding the pref in libpref/src/init/all.js. Easy enough to move but might affect other products (though I think mobile overrides this pref on their own).
Assignee: nobody → paul
Status: NEW → ASSIGNED
Attachment #388744 - Flags: review?(vladimir)
Comment on attachment 388744 [details] [diff] [review] Patch v0.1 Posted this to the wrong bug... Sorry.
This year we mothballed windows mobile development. See: http://blog.pavlov.net/2010/03/22/stopping-development-for-windows-mobile/ Marking bugs in the windows mobile / windows ce bucket as WONTFIX.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
Whiteboard: [nv] → mothballed
You need to log in before you can comment on or make changes to this bug.