Closed Bug 197671 Opened 22 years ago Closed 22 years ago

Separate "When Navigator starts up" from "What a new tab/window does" preferences

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: vincent-moz, Assigned: iannbugzilla)

References

(Blocks 1 open bug)

Details

(Keywords: perf, regression, Whiteboard: [adt2]Please do not debate pros/cons of home page in new tab - focus on a preference.)

Attachments

(2 files, 17 obsolete files)

Patch v1.6b
3.10 KB, patch
jag+mozilla
: superreview+
Details | Diff | Splinter Review
Quick Fix Patch v.3
661 bytes, patch
jag+mozilla
: review+
jag+mozilla
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.4a) Gecko/20030315 Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.4a) Gecko/20030315 In the past (until recently), it was possible to start Mozilla, asking to open the home page by default, while having a blank URL when opening new tabs. Now, this is no longer possible since new tabs now takes the "When Navigator starts up" option for their behavior, instead of using a new option. This is an annoying regression. Reproducible: Always Steps to Reproduce:
I'll confirm this. To clarify: your summary mentions new windows, although your description only talks about tabs. I'm assuming that you want this to cover both new tabs AND new windows, not just new tabs?
Status: UNCONFIRMED → NEW
Ever confirmed: true
We should at least be able to have a hidden backend pref for this without too much trouble. (I would think.) Currently we have "user_pref("browser.startup.page", [1-3]);". We could add something like "user_pref("browser.new.page", [0-3]);" defaulting to "0" which would have it simply follow what the startup option is currently set to.
CCing jag due to his work on the existing tabbed browsing portion from bug 109551.
Er - this is actually an enhancement request. (Nothing's actually broken here.)
Severity: normal → enhancement
Yes, I strongly support either reverting opening new tabs to the previous (blank) behavior, or adding some form of preference as described in this bug. Until the (in my eyes) ill-conceived fix for bug 109551 went in, I had set my home page to my favorite news page. At the beinning of my day, I started up my browser, and had my regular news fix served up for me. I read the news, and went about my business, sometimes opening new tabs, to do new tasks. The problem is that the news site is moderately complex, and takes some time to render, sometimes even blocking the UI for a second or so - no desaster, but * very* annoying when this happens with *each and every* new tab I open; even more so when the content displayed in the new tab is by now completely irrelevant, since I have already read it. To make matters worse, on my home machine, I have a demand-dialling internet connection. I use mozilla both to browse the internet and to browse local programming reference. Until recently, I had a homepage defined, and I could use 'New Tab' to access local documentation. Now, every time I open a new tab, my (external) home page got called, and initiated a demand dialup. In both cases (home and office), the 'fix' for bug 109551 lead to me moving to an empty home page. Effectively, the fix for something I didn't percieve as a bug took away a useful feature, namely the ability to define a homepage. The loss is small (I now have to press a button in my personal toolbar right after startup), but it is still a small loss of efficiency. To me, it seems like having new tabs open the homepage takes care of a *very* specialized use case, where somebody does the majority of their browsing from one special location, which is defined as the homepage. How common is this scenario? For me, I basically never happens. In my eyes, unless there is some study proving that this use case is by far the most common, the situation where taking care of specialized needs makes using a generally accepted and used feature much more cumbersome calls for a preference. Which of the two behaviors is to be the default is a difficult design decision, which will probably generate some debate anyway; but I strongly believe there should be at least a hidden preference to restore the old behavior.
Christian: Here's a workaround for your current problem (at least until this can be sorted out). Modify the shortcut you use to launch Mozilla by appending the name of your home page. (E.g. "mozilla myhomepage.com") That way, Mozilla will always launch with your home page loaded when you run it. Now tell Mozilla, in the preferences, to startup with a blank page. In this way, you'll always go to your home page on startup (the command line will override the startup option), the home page button will take you to your home page, but new tabs will be blank as before.
Re comment #1, I spoke about new tabs because this is what I use, but I think we should have the same behavior for new windows (as far as I'm concerned, I don't need separate options for new tabs and new windows, but I don't know if other users would need that). Re comment #4, the existing independence between startup and new tabs has been broken by bug 109551 fix, that's why I filled this bug as a normal bug.
the wording is currently wrong ("When Navigator starts up display"). Netscape 4.7x loads also the homepage if you open a new window and the wording there is "When Navigator starts". The current solution is NOT broken, it's expected and there should not be a difference between a NEW Tab and a NEW Window. (it was broken before this bug got fixed) We need either a chechbox with "load Homepage in new browser windows" (windows should also apply to Tabs) or change the current wording (and mark the checkbox solution wontfix or add a hidden pref for that). There is also a workaround/solution : set "when Navigator starts up" to blank and load Mozilla with "mozilla http://homepage.com" and you get exactly what you want. -> XP APPS because preferences is wrong for the panels itself
Assignee: ben → jaggernaut
Component: Preferences → XP Apps
QA Contact: sairuh → paw
> Netscape 4.7x loads also the homepage if you open a new window and the > wording there is "When Navigator starts". We're not filing a bug for 4.7 - we're talking about the latest Mozilla trunk build which does use the current wording under Preferences -> Navigator. Unless I'm missing something. Noboby's arguing that new tab and new window should behave different. Only that what happens at *startup* should be able to be different than either a new tab or a new window (which would both be the same). As for the "it's broken" issue - it's by design by the module owner so, by definition, it can't be broken. > We need either a chechbox with "load Homepage in new browser windows" Ack, no. What's the point? New tabs and new windows should do the same thing. If you *really* want them to behave differently (although I think that would introduce far too much complexity and would really not be worthwhile), you can file yet another bug. But this one is only about separating startup behaviour from the rest.
>New tabs and new windows should do the same thing. Yes, that's the point. I mean that this checkbox should also affect a new Tab. (And I agree that we should have such a pref !) I killed bug "197610" because it's no bug. Jag fixed the unequal behaviour between a new Tab and a new window.
This is ridiculous. A pref was what bug 109551 was all about. It simply isn't fixed. This shouldn't be an RFE. It is bad user interface, and even worse when the pref says one thing and does another: It should open homepage on startup, not on new tab.
Concerning the proposed workaround, I start Mozilla in various ways (either via the command line or the window manager...), and as my home page sometimes changes, this makes things tedious. So, a preference in Mozilla (that could be put in my user.js and thus would be global) would really be useful.
> as my home page sometimes changes, this makes things tedious. Vincent: Try this further workaround. Set your shortcut to the following: mozilla.exe javascript:home() This will load Mozilla with whatever your Home page of the moment happens to be. (Note: This does not work if you have a tab group defined as your home page - see bug 172657.) > A pref was what bug 109551 was all about. Bug 109551 was about changing the behaviour of new tabs so that they were not hardcoded to do something. There were various resolutions proposed, and one of them was decided on. Perhaps the summary should have been changed, but new tabs are now no longer hardcoded but are based on other settings that you have. There are interim workarounds, already discussed here, to get back to the old behaviour until this bug can be resolved. (Which, so far, nobody here has been arguing against.) > This shouldn't be an RFE. Current behaviour is as intended and "by design" per the module owner. You personally may not like it, but in Bugzilla terms any change to intended behaviour is an RFE.
Bug 109551 was spun off from bug 105589 where Hyatt, the original module owner, writes: "I don't believe tabs should ever load the home page" Summary of bug 109551 still reads "prefs to show home/current/blank page in new tab". Similar requests are in several of the duplicates. This isn't the only sample of tabbed browsing being slowly broken: See bug 103354 and spinoffs for further samples of whimsical treatment of features in what might be THE most vital lead Mozilla has on MSIE. Seems to me that development of the tabbed browser has lost all direction. I can't make myself believe this is done on purpose.
Keywords: perf, regression
QA Contact: paw → sairuh
Jason: I'm not under Windows. I sometimes start Mozilla from the command line, sometimes with a relative path (I sometimes have several versions installed on my machine). Moreover, will javascript:home() work if JavaScript is disabled?
> I sometimes start Mozilla from the command line, sometimes with a relative > path You could rename the Mozilla executable and drop in a script with the original name that calls the new file with the startup page - in each instance. > will javascript:home() work if JavaScript is disabled? No. And I don't know how to enable it only for localhost (or that one function). Sorry, there's a point at which workarounds don't cover all circumstances. Obviously, nobody disagrees that the best solution here is to just resolve this bug somehow...
I have to agree: this issue has not been resolved by the patch for bug 109551. The important thing here is making the tabbed browsing experience as smooth as possible for as many people as possible. Making new tabs behave identically to a new window will satisfy some people, but not others. There are good reasons for wanting to make them behave differently. The example in comment #5 is one; my own case is another. My homepage is set to a file on my hard drive that contains links to the sites I visit most frequently. When new tabs auto-opened to about:blank, I always had to hit the Home button before I could continue working, which was terribly annoying. The slow-to-load news site example works the other way, but the effect is the same: reduced efficiency and a higher annoyance coefficient. Face it: different people have different usage patterns, and the only way to well and truly solve this issue is to make it configurable. Ideally this would appear in the prefs panel. And just to head off the inevitable complaints about bloat, this is not bloat, it's the cure to it. This is merely offering a reasonable level of personalized control over an existing feature. Imho, offering control over an existing feature is *never* bloat. Having features without offering control over them *is* bloat. (Which, on a side note, is my personal peeve against Phoenix: there is a LOT of functionality that they have but don't offer easy control over.)
*** Bug 198084 has been marked as a duplicate of this bug. ***
*** Bug 198143 has been marked as a duplicate of this bug. ***
This makes opening a new tab a pain for a lot of people. Is this really of "enhancement" severity, since it is a regression? Wouldn't "trivial or higher be more suited, at a minimum? Voting for this bug...
I also find the behaviour of new tabs opening a homepage very annoying. Yes, the workaround fixes it (for me and my usage pattern) but in my view the previous behaviour should be restored and when the mechanism is in place for separating start-up from new tab behaviour that blank url should be the default for new tabs. Voting ...
> Is this really of "enhancement" severity, since it is a regression? Yes. There is no such thing as "enhancement severity" - an enhancement request is not the same thing as an indication of severity. You can have an enhancement request that's a "major" bug - but still be an enhancement. (See bug 9412 on changing this state of affairs.) The correct way of indicating severity on an enhancement request is not to change it from "enhancement" but to set the priority flag. (Eg. P1, P2, etc., where the lower that value the more important it is.) However, I believe that only the person to whom the bug is assigned is supposed to do that, so please don't rush off to set this bug's "P" level...
IMO we're talking about three different things here. The current pref says "When Navigator starts up display...", this is not the same as "When opening a new window display..." or even "When opening a new tab display...". These are three different things and if done properly should have three different settings. People use their browsers in different ways. Personally I don't know why I would need a new window to open my home page. And I definitely don't want my tabs to do it. I open new tabs and windows to enter an URL by hand; if I want to load my home page I can hit the proper button. I hardly ever open a new page, but I'm sure people who do it, have them for the different uses than tabs. So again: we need three options for this: one which definies what happens at startup, one which defines the beviour for opening new windows, and one for new tabs.
*** Bug 200276 has been marked as a duplicate of this bug. ***
Since I like the behaviour of opening a blank tab better than loading some page and I noticed this has changed in version 1.4a for Linux, I filed a bug (bug 200276) and was redirected to this bug report. Reading all the patches and comments here I was able to produce a fix that 1) will just start mozilla with a page of my choice just giving the mozilla command, without any command line options 2) will open a blank page when pressing Control-T, or selecting File->New->Tab 3) will still open a page when using the middle mouse button on a link or typing it in the location bar and hitting Control-Enter. This is how to do it : - create a backup of comm.jar - unjar is and edit the file content/navigator/navigator.js - in the function BrowserOpenTab, uncomment (or remove) the lines that say var uriToLoad = handler.defaultArgs.split("\n")[0]; if (/^\s*$/.test(uriToLoad)) - create a new jar archive called comm.jar from the content subdirectory and (re)start mozilla. I'm not sure, however, if this will introduce any errors, but so far it seems to work fine.
> will open a blank page when pressing Control-T Remember that any actual patch to this bug will not be something that forces a blank page with a new tab but one that let's the user choose what will happen with a new tab.
> Remember that any actual patch to this bug will not be something that forces a > blank page with a new tab but one that let's the user choose what will happen > with a new tab. Sure. I never claimed it was a patch. It's only another workaround for people who don't like the other presented workarounds. But I would appreciate a permanent fix like that much.
I for one LOVED the way opening tabs was behaving before it got "fixed". I personally also - both, at home and at wotk hav a news site set up as my home page. When I open new windows or tabs - I do this only to open some bookmark or enter new url for this tab (or if I want some external program to open a link in a new tab) In any case - loading the page that was set up as my home page, every time I open new tabs, is overkill, scince only time I might actually be interested in the cntent of thet page is when I first start up my browser. Rest of the time it's for new content... Anyway - scince hardcoded about:blank is also bad (for all the reasons in Comment #17), I propose an additional pref for opening new tabs/windows: 1 - about:blank 2 - default homepage 3 - custom page. Anyway - Im voting for this bug....
*** Bug 200390 has been marked as a duplicate of this bug. ***
*** Bug 200400 has been marked as a duplicate of this bug. ***
I've been dealing with this bad loading home page in new tabs **** for a few days now and you know what I found it has led to? I'm using Safari more. Well Safari build v62 (the first build with tabs) anyway. Seriously this has got to stop before I murder someone. Please make it go back to the old behaviour of Cmd+T dropping you in a freshly blank tab with the cursor in the location bar. If I wanted to see my home page again, I would either click the home button in the toolbar, or I would hit Cmd+W and open a new window. Anyone know what the last nightly was before this braindead behaviour began so I can use that build? Otherwise I guess I'll go back to 1.3. Someone should request that this blocks 1.4b.
I agree with comment #31. It is almost unbearable, especially in Unix/Linux since copy/paste functions are sensitive to highlighting text. One way of opening the home page in a new tab is to drag the home link from the personal toolbar to the new tab button. A second way is to add the same context menu of a link on a web page to the location bar URL icon when it is right clicked. Or add a pref. This should be fixed as soon as possible.
Reads from prefs to find out what to load in new tab. Uses two new prefs - browser.tabs.startup.homepage and browser.tabs.startup.page (these are the same names as the equivalent browser.startup prefs, for consistency). browser.tabs.startup.page takes the following values: 0 - Load tab with blank page 1 - Load tab with default homepage 2 - Load tab with last page visited 3 - Load tab with value of browser.tabs.startup.homepage Note that you will need to add these prefs manually at present, otherwise opening new tabs will break [getCharPref() and getIntPref() seem to throw exceptions if the relevant pref doesn't exist). This patch isn't ready to be checked in for this reason - does anyone know where I need to add new prefs?
Thank you, Chris, for submitting a patch! One note: This bug is actually not *just* about new tabs, but also about new windows. (The summary reads "new tab/window".) While Navigator may start with your home page, if you want new blank tabs for reasons of bandwidth, it's also assuming here that when you open a new window it, too, should be blank. Additionally, I think that using "start" in your preference name would cause more confusion over how Navigator "starts" and what "new" tabs/windows should do. Lastly, I don't think that we (at the moment) want to deal with the added complication of having new tabs/windows do something *different* than opening as blank, home, or last page as already defined. For all of the above, I believe you should consider just a single preference that's renamed to "browser.new.page" that does the following: 0 - Load new tab/window with blank page 1 - Load new tab/window with default homepage 2 - Load new tab/window tab with last page visited
Why can't it just go back to the old behaviour that we've had for the last year and a half? * New windows do whatever you have configured in the "When Navigator starts up, display" preferences. * New tabs open blank page with cursor in location bar. Please just return it back to the old behaviour. Go ahead and create prefs to do whatever mind-numbing config bloat that 1% of the population wants, but please just put the defaults back the way they were.
> Why can't it just go back to the old behaviour that we've had for the last year > and a half? > > * New windows do whatever you have configured in the "When Navigator starts up, > display" preferences. > * New tabs open blank page with cursor in location bar. Perhaps you don't remember, but originally new tabs did the same thing as new windows. Then somebody changed new tabs to open a blank page. This caused a whole slew of bugs to be filed, including ones where people said "Why can't it just go back to the old behaviour?". So obviously, to make everybody happy, this needs to be configurable. And I personally believe that either all three events (first window, new window, new tab) should each have their own setting, or that new windows and new tabs should behave the same way.
Re comment #33 and comment #34, I don't know if we should have different options for new tabs and new windows, but some users may want them to behave differently (see comment #17). But an important point is that we should have only one homepage, otherwise this would be very confusing. So, a pref browser.tabs.startup.homepage would be a bad idea.
> I don't know if we should have different options for new tabs and new windows My feeling is that we should do whatever will generate a patch to address this bug as quickly as possible (if we try to come up with something that handles the two separately it will just take that much longer to resolve) - the easiest is to combine the two components right now then deal with any possible separation in a different bug. (On a purely *personal* note, I should perhaps mention that I'm perfectly happy with things as they stand now. I actually prefer to have my home page appear in all new tabs and windows. I've also seen other people request the current behaviour before things got "fixed", so I know I'm not alone. It's only those who don't like things that are the most vocal. However, I recognize the difficulty that this is causing for other people, and it's no better simply replacing one group of unhappy people with another. So, in order to make sure that nobody is unhappy we really do need to make this a matter of user choice.)
I realize that different people have different behaviours but the current behaviour really seems not logical to me. I start a browser once per session, so the loading of the startup page is a "once a session action"; on the other hand I open a lot of tabs and windows many times during one browser session, these are repeated actions. It really makes no sense to force the same behaviour on completely different things, it doesn't follow any logic. To me that's almost like showing a splash screen every time I open a new window.
People, please let's not debate this issue. It will only take away from a resolution that *everybody* can be happy with. Let's work on fixing this bug and getting a preference in place.
Whiteboard: Please do not debate pros/cons of home page in new tab - focus on a preference.
navtriage: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: Please do not debate pros/cons of home page in new tab - focus on a preference. → [adt2]Please do not debate pros/cons of home page in new tab - focus on a preference.
Updated version of Chris's patch with only one new pref now "browser.tabs.page" and only 3 options after removing the custom page load. Also added missing ; to case 1's break. Two more patches to come to add new pref to preferences UI.
Attachment #119448 - Attachment is obsolete: true
This is the first of 2 patches to add new pref to preferences UI for en-US locale. I presume other versions of this file would need to be created for other locales
This is the second of 2 patches to add new pref to preferences UI. These three patches have not been tested by myself so I'm hoping someone can look at them, test them if they look safe and report back here. Treat me kindly!
Attached file Counter-proposal for UI (obsolete) —
Here's a counter-proposal for the UI to implement those new prefs. I've never submitted any XUL to bugzilla before, so there's some submission protocol I'm missing, I apologize in advance. This attachment is a full copy of the modified pref-navigator.xul from my comm.jar. I haven't written any of the JavaScript to implement new functionality -- it works just like before, only there's a new drop-box that doesn't do anything. Also, the XUL is a bit rough -- I haven't declared entities for the caption/label strings, which are currently hard-coded and shouldn't be. But it's just a mock-up, after all. I'll post a PNG in a minute for those who don't want to muck about with their comm.jar but want to see it.
Attached image Screenshot of previously proposed UI (obsolete) —
The promised screenshot.
Oh heck. I've just looked at Ian's patch, and the UI is basically identical to the one I proposed. Guess great minds think alike. Sorry for the extra email! :-/
Comment on attachment 119501 [details] [diff] [review] Revised navigator.js with only 3 options instead of 4 r=me if: 1) You put add a try/catch around the getIntPref() call and default to something sane if it fails. 2) You give this a better pref name than browser.tabs.page. 3) You get sr from jag on all this stuff.
Attachment #119501 - Flags: review+
Comment on attachment 119502 [details] [diff] [review] Add new pref to preferences UI part 1 r=me if you change the "When Navigator starts up, display" text to something that would make sense in this context.
Attachment #119502 - Flags: review+
Comment on attachment 119503 [details] [diff] [review] Add new pref to preferences UI part 2 r=me. Oh, and next time just diff from xpfe/ or from toplevel and make a single patch file, ok? ;)
Attachment #119503 - Flags: review+
pref is now called browser.tabs.loadOnNewTab and added patch to all.js, on bz's suggestion, to add a default of 0 (load blank page) plus comments to explain what each value does.
Attachment #119501 - Attachment is obsolete: true
Attachment #119502 - Attachment is obsolete: true
Attachment #119503 - Attachment is obsolete: true
Attachment #119509 - Attachment is obsolete: true
Attachment #119510 - Attachment is obsolete: true
Attachment #119517 - Flags: review?(bzbarsky)
Comment on attachment 119517 [details] [diff] [review] Combined patch taking on-board bz's comments + // lets new tab load some different than new window "something different than first window" you mean? Also, you may want to move |var uriToLoad;| outside the try block; while what you have is valid JS, it looks funny. jag? Thoughts?
Attachment #119517 - Flags: superreview?(jaggernaut)
Attachment #119517 - Flags: review+
Attached patch Patch v1.2 (obsolete) — — Splinter Review
Moved var uriToLoad; out of try bloack and tweaked comment in all.js as per comment #52
Attachment #119517 - Attachment is obsolete: true
Attachment #119519 - Flags: superreview?(jaggernaut)
Attachment #119519 - Flags: review?(bzbarsky)
Attachment #119517 - Flags: superreview?(jaggernaut)
Attachment #119517 - Flags: review?(bzbarsky)
Comment on attachment 119519 [details] [diff] [review] Patch v1.2 "something", not "some". No need for a new patch; whoever checks in should just fix that....
Attachment #119519 - Flags: review?(bzbarsky) → review+
For people who hate the current behaviour as much as I do, the Tabbrowser extension (http://white.sakura.ne.jp/~piro/xul/_tabextensions.html) allows to fix the current behaviour. With it you can define, in a very detailled way, how tabs newly opened should behave.
Status: NEW → ASSIGNED
Hmmm, really assigning it to myself now
Assignee: jaggernaut → ian
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Re: Comment 42 (Removal of fourth option) After patching my own installation, I actually quickly grew to really like the ability to have separate settings for my homepage and for new tabs. I have a fairly complicated homepage that takes a few seconds to render, so for obvious reasons I don't want to have that load every time I open a new tab (that's why I patched it, it was driving me insane!)... but I quite like the idea of having Google open up automatically in new tabs. This is usually why I open new tabs anyway - to search for something. Would it be possible to reinstate the "fourth option", even without any UI? It seems to me to be useful functionality. I also agree with comment #35 that new windows should just obey the "when navigator starts up, display" option. Anything else just seems unnecessary.
Attached patch Patch v1.3 (obsolete) — — Splinter Review
Updated patch with following fixes: - typo mentioned in comment #54 - new part of UI no longer expands to fill whole of pref window - last page visited option now works, did not before because pref browser.history.last_page_visited has been removed
Attachment #119519 - Attachment is obsolete: true
Attachment #119627 - Flags: superreview?(jaggernaut)
Attachment #119627 - Flags: review?(bzbarsky)
Blocks: 200956
Re: Comment #57 This patch does mean that new windows obey the "When Navigator starts up, display" preference and that new tabs obey the new "When new Tab is created, display" preference. I've tried to mirror the options exactly that is why there is no custom page option. I've spun off the adding the custom page option as a separate enhancement bug (bug 200956) which could be looked at once this fix gets checked in.
Note: It wasn't/isn't the intent of this bug to have new windows behave the same as navigator startup. (For all of the reasons that new tabs shouldn't.) Separating tabs will be fine for a partial fix, but (unless the reporter disagrees) this bug should remain open after such a patch is checked in so that new windows either mirror new tabs or another set of preferences is also checked in for them.
I'm now working on the new window behaviour side of this patch. I do have a working patch that makes use of the tab behaviour preference but I would like the behaviours to be separate. This leads to the question what should the preference be called and where in the pref UI should it sit. One possible name for the pref is browser.windows.loadOnNewWindow (which follows the tabs pref browser.tabs.loadOnNewTab) or just have browser.loadOnNewWindow As far as the pref UI, it either needs to sit at the root of the navigator menu or have a new submenu created for it. I'll upload a screen shot of the former in a while.
Attached patch Patch v1.4 (obsolete) — — Splinter Review
This patch adds a, currently hidden, pref "browser.windows.loadOnNewWindow". When a new browser window is created from an already open browser window, the behaviour followed is determined by this new pref. 0 - Blank Page 1 - Home Page (default) 2 - Last Page Visisted
Attachment #119627 - Attachment is obsolete: true
Ian: perhaps the following would be more useful? -1 - Use "Navigator Startup" pref (default) 0 - Blank Page 1 - Home Page 2 - Last Page Visisted
Great work, Ian! You're doing a good job with all of this. (R.e. the "-1" for the same as Navigator startup. I'm not sure if we need this, but if it's implemented for new windows, it should also be implemented for new tabs.)
With all these extra prefs it's pointing towards having a new submenu off the navigator menu and putting both the new tab and new window behaviour choices inthere. I can't immediately think of a name for the new submenu.
Just a word of caution.. you may want to float such a proposal by the UI owner -- I suspect it will not pass muster.
If UI approval isn't forthcoming, how about just getting the backend prefs in place for now and then work on hammering out and hooking up UI afterwards in a different bug?
Might be a thought.... Again, my comments are just my comments, not policy or anything. ;)
Re comment #67: I blieve splitting the UI part off of this bug is a *very* good idea - UI discussions tend to be longish and complicated. Getting the backend preferences checked in will avoid a lot of frustration when the whole checkin is held up by discussions on UI aspects. Additionally, we're in a period of release freeze. The longer the whole thing takes to get checked in, the slimmer the chances will be, since tree control will be tighter and people will be even less ready to make UI changes.
Blocks: 201177
What I propose to do then is add the extra backend stuff for the -1 option for both tabs and windows, add the extra radio button in the UI for the tabs -1 option and see if I can get those fixes checked in. I've spun off the further UI discussion into bug 201177 to discuss later. Is it worth renumbering the options so: 0 - Use Navigator Startup Preference 1 - Blank Page 2 - Home Page 3 - Last Visisted Page ?
FWIW, I prefer the 0-4 numbering.
Attached patch Patch v1.5 (obsolete) — — Splinter Review
Renumbered Options and added new Option 0 (set as default) which makes the new tab/window behaviour same as navigator startup behaviour. Any comments back on naming of radio button and what the default setting for behaviour should be is welcome (as well as any other constructive feedback). It still needs testing though.
Attachment #119695 - Attachment is obsolete: true
I would set the default behaviour for new tabs and new windows to be blank (value=1) since this uses the least bandwidth and will cause the least inconvenience to dial-up users.
> + <radio value="0" label="&startupTabRadio.label;" accesskey="&blankTabRadio.accesskey;"/> Is this correct? Shouldn't the accesskey="&startupTabRadio.accesskey"?
Attached patch Patch v1.5a (obsolete) — — Splinter Review
Same as patch v1.5 except without pref UI part of it, this has been spun off into patch for bug 201177 (version 1.0a which includes the typo caught by Jason)
Attachment #119816 - Attachment is obsolete: true
Attached patch Patch v1.5b (obsolete) — — Splinter Review
Default option for new window/tab is now set to 1 - blank page
Attachment #119821 - Attachment is obsolete: true
Attachment #119905 - Flags: superreview?(jaggernaut)
Attachment #119905 - Flags: review?(bzbarsky)
I'd rather keep the pref values in sync with the startup ones. Stick to -1 to indicate "do whatever we do for startup".Instead of getting the current url from getWebNavigation() (which would fail for opening a new nav window from mail/news), do what's done in http://lxr.mozilla.org/seamonkey/source/xpfe/browser/src/nsBrowserInstance.cpp#793 (get the history service and ask it).I think the code might be a little clearer when you move |startpage = handler.defaultArgs;| inside the switch (but keep the |var startpage| where it is).My apologies for not speaking up sooner.
Sigh. Either certain browsers out there need to fix their textarea wrapping before they submit, or bugzilla needs to be fixed. Once more, better laid out: I'd rather keep the pref values in sync with the startup ones. Stick to -1 to indicate "do whatever we do for startup". Instead of getting the current url from getWebNavigation() (which would fail for opening a new nav window from mail/news), do what's done in http://lxr.mozilla.org/seamonkey/source/xpfe/browser/src/nsBrowserInstance.cpp#793 (get the history service and ask it). I think the code might be a little clearer when you move |startpage = handler.defaultArgs;| inside the switch (but keep the |var startpage| where it is). My apologies for not speaking up sooner.
Oh, and I agree with comment 73
I'm now looking at doing: var globalHistory = Components.classes["@mozilla.org/browser/global-history;1"] .getService(Components.interfaces.nsIBrowserHistory); startpage = globalHistory.lastPageVisited; but as far as I can see it always returns null, any ideas?
Ah, it's because we don't store the last page visited unless the browser startup pref is set to 2; see nsGlobalHistory::AddPage. See the blame for those lines. Fix seems easy enough.
Would an alternative way of fixing it be, going back to using getWebNavigation().currentURI.spec and make it so calling up a New Window from mail/news doesn't touch the new code which is what I was originally intending to do?
In fact my patch 1.5b is working how I originally intended it to work in that I wanted a New Window from mail/news to have the behaviour of Navigator startup. My interpretation of the original "When Navigator starts up, display" preference was it determined the behaviour the first time a browser window is created, either by starting Navigator or starting another component and then bringing up a browser window.
Attachment #119519 - Flags: superreview?(jaggernaut)
Attachment #119627 - Flags: superreview?(jaggernaut)
Attachment #119627 - Flags: review?(bzbarsky)
Attached patch Patch v1.6 (obsolete) — — Splinter Review
Updated patch to reflect jag's comments about moving |startpage = handler.defaultArgs;| inside the switch and the fact navigator.js is now at 1.499 Left getWebNavigation().currentURI.spec as it was (see comment #83) Will be attaching an updated patch to bug 201177 which will work with this patch.
Attachment #119905 - Attachment is obsolete: true
Attachment #119905 - Flags: superreview?(jaggernaut)
Attachment #119905 - Flags: review?(bzbarsky)
Attachment #120119 - Flags: superreview?(jaggernaut)
Attachment #120119 - Flags: review?(bzbarsky)
bz/jag review? comments?
Comment on attachment 120119 [details] [diff] [review] Patch v1.6 sr=jag. Just wondering now if we could refactor this code to share the switch.
Attachment #120119 - Flags: superreview?(jaggernaut) → superreview+
jag: unlikely, because (unlike new tab) new window wants to open all home tabs.
For the purposes of this comment if we assume that the home page is set to a group and that all prefs are set to home page (both prior to and after this patch). This patch does change the behaviour of New Window (Ctrl-N) from an existing browser window. Prior to this patch it would open the whole group, after this patch it would behave similarly to New Tab (Ctrl-T) and just open the first page of the group. Is this change to its behaviour acceptable? The old behaviour can still be made to happen by setting the New Window behaviour pref to be Navigator startup page.
My personal opinion is to lean slightly in favour of opening all tabs in a tab group in a new window, if the it's set to go to home and home is such a group. Otherwise it's slightly misleading. Also some people <sigh> might want a new navigator session to do something other than go to their home page, but still have new windows go to their home page... Having said that, I don't really think it's a big deal.
It should open the group of tabs.
I'm running today's build. It has regressed horribly, on account of my home page showing up in new tabs. This needs to be fixed for 1.4b. /be
Flags: blocking1.4b?
Flags: blocking1.4b? → blocking1.4b+
Attached patch Patch v1.6a (obsolete) — — Splinter Review
New Window when set to home page now displays home page group if there is one.
Attachment #120119 - Attachment is obsolete: true
Comment on attachment 120258 [details] [diff] [review] Patch v1.6a Requesting review and superreview
Attachment #120258 - Flags: superreview?(jaggernaut)
Attachment #120258 - Flags: review?(bzbarsky)
I will not be able to get to this until at least Monday afternoon.... I'll try then, but no guarantees -- the real world is catching up with me.
Adding some XP-Apps peers that might want to comment/review this patch and the one to bug 201177
*** Bug 201915 has been marked as a duplicate of this bug. ***
Comment on attachment 120119 [details] [diff] [review] Patch v1.6 Consider changing if (/^\s*$/.test(uriToLoad)) to if (!/\S/.test(uriToLoad))
Attachment #120119 - Flags: review?(bzbarsky) → review+
Attached patch Patch v1.6b — — Splinter Review
As v1.6a but with (!/\S/.test(uriToLoad)) as suggested by Neil in bug 103329c#19 and Timeless
Attachment #120258 - Attachment is obsolete: true
Comment on attachment 120258 [details] [diff] [review] Patch v1.6a Cancelling old r/sr requests
Attachment #120258 - Flags: superreview?(jaggernaut)
Attachment #120258 - Flags: review?(bzbarsky)
Comment on attachment 120517 [details] [diff] [review] Patch v1.6b Requesting formal r=/sr= and then can someone check it in?
Attachment #120517 - Flags: superreview?(jaggernaut)
Attachment #120517 - Flags: review?(timeless)
Comment on attachment 120517 [details] [diff] [review] Patch v1.6b sr=jag
Attachment #120517 - Flags: superreview+
i know that the frontend (bug 201177) hasn't been fixed yet, but since this was checked in on 14-april-2003 18:49, should this be resolved now? or is there more backend work expected here? fwiw, this is what i see with today's (203.04.15) builds: 1. "home page" selected for "when navigator starts up" in Navigator pref panel. i also have either a page url or a groupmark set for the home page location in this panel (doesn't matter which). 2. quit and restart app. resulting browser page opens to the location set in (1). 3. open a new browser window via accel+N or from the main menu, File - New - Navigator Window. results: the new browser window is blank. is this expected with the current state, or is it a new regression?
shouldn't the default not be changed to enabled instead of disabled ?
This is what is expected, the default setting for new window is a blank page, as it is for new tab. It probably is best that the default settings for the two new settings, until the pref ui bug is checked in, should be -1 which is the setting for same behaviour as navigator startup.
Attached patch Quick Fix Patch (obsolete) — — Splinter Review
Patch to set default for two new prefs to be -1 which means new tab/window behaviour will be set to same behaviour as when navigator starts up.
Attachment #120638 - Flags: superreview?(jaggernaut)
Attachment #120638 - Flags: review?(timeless)
Attached patch Even quicker fix (obsolete) — — Splinter Review
Only changes the behaviour for new window to be the same as for navigator startup (i.e. -1 ignore new code)
Attachment #120638 - Attachment is obsolete: true
Comment on attachment 120638 [details] [diff] [review] Quick Fix Patch Cancelling r=/sr= requests on this patch
Attachment #120638 - Flags: superreview?(jaggernaut)
Attachment #120638 - Flags: review?(timeless)
Quick fix patch v.3 with proper diff (just for timeless)
Attachment #120640 - Attachment is obsolete: true
Comment on attachment 120642 [details] [diff] [review] Quick Fix Patch v.3 Request for r=/sr= so it can be checked in
Attachment #120642 - Flags: superreview?(jaggernaut)
Attachment #120642 - Flags: review?(timeless)
Comment on attachment 120642 [details] [diff] [review] Quick Fix Patch v.3 r=/sr=jag. I'll check this in.
Attachment #120642 - Flags: superreview?(jaggernaut)
Attachment #120642 - Flags: superreview+
Attachment #120642 - Flags: review?(timeless)
Attachment #120642 - Flags: review+
Marking as fixed.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
thanks, ian! vrfy'd fixed with 2003.04.23 bits (still pending bug 2001177, o'course).
Status: RESOLVED → VERIFIED
Attachment #120517 - Flags: superreview?(jaggernaut)
Attachment #120517 - Flags: review?(timeless)
"(still pending bug 2001177, o'course)" Nope, make that bug 201177 :-)
*** Bug 203863 has been marked as a duplicate of this bug. ***
Strange...can't add myself (spooky130@cox.net) for CC: on this bug.... Why is this debate even going on now? HJ fixed it back in, oh, October or November (not sure, but it was somewhere around that time).... The pref is already there. See Edit->Preferences->Multizilla->Links ... and from there, two items: * Preferred location for opening new tabs (entry) * Use preferred location for new tabs (checkbox) It's already fixed, and it works fine (well, except for more recent issues with new windows opening *UNDER* the current window and with the original startup tabset instead of the preferred location ... see bug 3673, which I filed a few days ago).
> See Edit->Preferences->Multizilla->Links The problem is, I don't see any "multizilla" under preferences.
That's for the multizilla addon and this is not the place to add comments about UI things in multizilla.
Ok, I feel embarassed now.... I was reading the Multizilla list, and ended up here somehow. I thought I was still there. Never mind.
*** Bug 204699 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: