Closed Bug 102120 Opened 23 years ago Closed 23 years ago

Opening a link in a new tabbed browser should not necessarily switch to that tab automatically

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: adam, Assigned: hyatt)

References

Details

Attachments

(3 files)

Proposed patch, adds a pref
1.54 KB, patch
Details | Diff | Splinter Review
New patch; removes pref init as it is indeed a global.
1.19 KB, patch
Details | Diff | Splinter Review
Patch to make tabs load in background based off SHIFT+CTRL+click, SHIFT+middleclick, and a pref
3.59 KB, patch
bryner
: review+
hewitt
: superreview+
Details | Diff | Splinter Review
For those of us who like to head-recurse, it would be fabulous to be able to middle-button-click all interesting links on a page, nestling them into their own tabs in the background, without automatically switching to the new tab and then manually back again for each click.
-> tabbed browser
Component: XP Toolkit/Widgets → Tabbed Browser
QA Contact: jrgm → blakeross
See also bug 56690, the non-tabbrowser version of this bug.
*** Bug 102434 has been marked as a duplicate of this bug. ***
*** Bug 102451 has been marked as a duplicate of this bug. ***
Looking at the bug I found this line which should do the trick, albeit only for tabbed browser: http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/contentAreaUtils.js#93: browser.selectedTab = browser.addTab(url); => browser.addTab(url); Haven't tested it, though
I have been thinking the same thing. The 'open link in new tab' option shouldn't switch to the new tab or there should be an option at least for this. When I'm reading a page and see a link I want to check out I typically want to continue reading the current page while the other page loads in the background. This is especially true when I'm on a dialup connection. Having this option would be ideal as it doesn't interrupt my reading. Sounds like a useability win to me.
Sounds like somethign that could be pref-controlled, since I imagine some users will want the switch and some won't.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
I browse like this and this has always been a problem with new windows. A pref would be great, but maybe something like ctrl-click on Open in New Tab to do the alternate choice would be nice.
Feedback on the patch would be appreciated. It checks for a new pref "browser.tabs.openlinksinbackground" (defaults to false).
pref is a global var I think, so you shouldn't need to re-obtain it at the start of the function.
*** Bug 104365 has been marked as a duplicate of this bug. ***
What about: middle-button-click -- new tab + change focus shift + middle-button-click -- new tab + don't change focus. That's similiar to how it is done in Opera.
*** Bug 104994 has been marked as a duplicate of this bug. ***
There needs to be some way to do it without a third mouse button. Remember, this has to run systems with a two-button mouse or, heaven help them, Macs with a one-button mouse. Having it in the Preferences is a good way to go.
What about: shift + left-button-click -- new tab + change focus ctrl + shift + left-button-click -- new tab + don't change focus middle-button-click -- new tab + change focus ctrl + middle-button-click -- new tab + don't change focus.
What about: shift + left-button-click -- new tab + change focus ctrl + shift + left-button-click -- new tab + don't change focus middle-button-click -- new tab + change focus ctrl + middle-button-click -- new tab + don't change focus.
Problem with bucky-clicking things is getting them documented adequately. Also, shift-click already has a (very imporant) function; if you didn't know this, it testifies to the fact that it's hard to make the user aware of such things. I'm thinking the right-click context menu item should be just like it is (open in new tab), but there should be a preference as to whether or not such new tabs receive focus (and this could also apply to Ctrl-T new tabs). Alternately, there could be two separate items on the context menu, but that might be too much clutter.
Jonadab: I can't see why anyone would want Ctrl-T tabs to not have focus. What's wrong with something simple in the prefs, like this? Middle clicking a link opens it in: o New window o New tab New windows / tabs appear o On top of all preexisting ones o Below all preexisting ones (On a Mac, "Middle clicking" would be replaced by whatever Ctrl-click, Apple-click, Option-click, Commodore Key-click or whatnot it takes to open a link in a new window on their OS) If you wanted to quickly use the alternate actions, you could just use the context menu. I'm not opposed to the bucky shift-meta-alt-control-middle-click sequences being there, but you can't make them the primary means of doing this.
> I can't see why anyone would want Ctrl-T tabs to not > have focus. I would want it that way, I think. Maybe I think ahead more than the next guy, but I don't like to wait for a page to load up, even if it's my home page that I visit every time I open my browser. So I open a new tab before I'm ready to use it sometimes. But you have a valid point, that someone may not want it who does want link-context-menu tabs to open without focus, so perhaps that should be a separate pref. My point also brings up a separate point: maybe new tabs shouldn't always bring up the home page? (If so, that needs probably to be a separate RFE and yet another preference, which I am willing to file if there isn't one already. Looks like maybe tabbed browsing deserves a whole subsection of the browser preferences...) Agree about buckies: nice to include them, but they shouldn't be the only way to achieve something. BTW, above where I said "right-click context menu" I of course mean the context menu however it is reached (e.g., half-click on a Mac, right-click on XFree or Windows, whatever).
QA: Ignore Sorry, i have Moz set to start with a blank page, so i thought new tabs always start with a blank page. That's why i thought nobody would ever want Ctrl-T -- who would want a new, blank page at the bottom of their tab stack? But i can see how this would be useful if you have a home page.
Target Milestone: mozilla1.0 → mozilla0.9.6
Comment on attachment 54091 [details] [diff] [review] Patch to make tabs load in background based off SHIFT+CTRL+click, SHIFT+middleclick, and a pref r=bryner
Attachment #54091 - Flags: review+
Comment on attachment 54091 [details] [diff] [review] Patch to make tabs load in background based off SHIFT+CTRL+click, SHIFT+middleclick, and a pref sr=hewitt
Attachment #54091 - Flags: superreview+
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 105869 has been marked as a duplicate of this bug. ***
Verified fixed. Cheers, hyatt.
Status: RESOLVED → VERIFIED
Bug 105589 resolves the issue of tabs that take time to load, thereby making it unnecessary for new blank tabs (e.g., those opened with Ctrl-T) to have this pref also. Thus, the fix as it stands should be sufficient.
*** Bug 106432 has been marked as a duplicate of this bug. ***
*** Bug 106547 has been marked as a duplicate of this bug. ***
Please repoen, it's still happeneing to me on win32 2001102403 on win2kpro-sp2, the pref to open tab in background is unchecked.
lohphat, If the pref is unchecked, then it *should* be still happening. When it should NOT happen the old way is if the pref is checked. Please clarify whether there is a difference when the pref is checked.
Pref is UN-checked, new tabs still load *under* current content. But I may be having other issues as the build I'm now using crashes when I openen a new window with my default homepage set to: http://home.earthlink.net/~lohphat/
URL you cite seems fine to me, mostly old standby HTML stuff that's been around since HTML 2, transitional doctype, should be fine. Tried unchecking the pref myself, right-clicked on your link and chose New Tab, focus switched to new tab "Hello". Hit Ctrl-T, focus went to new untitled tab. This is 2001102309 on Win95 OSR2, however, and your build number seems newer, so I will fetch a fresh nightly and retry this. Regarding the crash, suggest you also try a different build, that page seems fine to me.
As of today's build, 2001102503 win32 on win2kpro-sp2, new tabs still open under the current content *and* now no longer display the X close button in the upper right corner.
I can _partially_ reproduce this with 2001102503, Win95 OSR2 With "Load Links in Background" _un_checked: * Ctrl-T opens a new tab and changes focus to that tab (CORRECT). * right-click on link, "Open in New Tab" opens a new tab, loads the link in that tab, but does not change focus; current tab (the one where I right-clicked on the link) remains in the foreground, and the new tab with the content referenced by the link is background (INCORRECT). With "Load Links in Background" _checked_: * Ctrl-T opens a new tab but changes focus to that tab (INCORRECT). * right-click on link, "Open in New Tab" creates a new tab, and loads the link in that tab in the background (CORRECT). That is, the pref doesn't seem to be having the intended effect, or any effect at all for that matter. new empty tabs seem to always take the focus, and new tabs opened via the link context menu do not. lophat, are these results the same as you are getting with the same build? This was not the case when the pref was added at first; see my earlier comment regarding 2001102309, which I am fairly sure behaved correctly in all four cases. Maybe a minor regression.
Ignore what I said about Ctrl-T tabs recently. I forgot momentarily about Bug 105589. What I said about tabs opened via context menu still applies. Sorry for the confusion.
Yes! *sniff* someone believes me! *snif* It's open in new tab from the right-click context menu which is failing. Should this be reponed?
If it fails in 0.9.6, we should reopen it, but since it was temporarily fixed and only regressed very recently, I think we should give it a few builds to resolve before we panic.
This seems to be working correctly again in 2001102708, lohphat please retest.
The latest Mac build as of late 10-27 is still 2001102608. Tabs now can be opened behind; a *nice* feature. They can be closed either when frontmost, or when behind; also very nice. But, somewhere along the way, the tabs got much wider than they had been. I liked them better narrow, as I like to open lots of pages for future reading. Could the tabs "shrink" when they fill the window from side to side, so no matter how many were opened, there'd always be something showing for each of them?
1) open in new tab still open behind current pane. And yes, the large tabs are annoying too. I can't reproduce it, but several times when I choose close tab in a newer tag, the older tab closes.
> But, somewhere along the way, the tabs got much wider than they had been. This happened when the feature was added that lets them resize automatically according to how many you have open, see Bug 101774 too many tabs prevents vertical scrollbar from appearing > I liked them better narrow, as I like to open lots of pages > for future reading. What happens when you open a lot of pages? If they don't shrink, post your comments on bug 101774. > 1) open in new tab still open behind current pane. Even with "load links in background" _unchecked_? What build?
Hey lophat, try deleting the XUL.mfl file in your profile directory. It's a file generated by mozilla to make it launch faster, but it hasn't been replaced when newer versions of moz are installed. Deleting it cured my ails with some other problems.
>> 1) open in new tab still open behind current pane. > Even with "load links in background" _unchecked_? > What build? For me, 2001102708
That did it. Now I found a nother problem (I'll look for, then open a new bug) that if your mail news is open and your open browser window is in tabbed mode, clicking on a URL in a mail message dosen't open in the browser window.
Just on a hunch: start the browser, but don't have mail/news open, set your pref to not load new links in background tabs (i.e., unchecked), and with just the browser open (no mail or news), try opening some links in tabs. Does it work with mail/news not open? I ask, because you have the same build I have, which works, but something must be different between our systems. I suppose it could be a W95/W2k difference, but that seems far-fetched for something so internal to the browser as tabs. Could also be some other pref having an impact, maybe we should compare preferences? If you still get the problem with mail/news not open, attach a copy of your prefs.js to an email and send it to me privately (well, you should remove any passwords first, e.g. for your mail server), and I will see if I can reproduce the problem using your prefs.
One quuick note... control click on the mac brings up a contextual menu. Their is now simple way to pick and choose if you want a link opend in a new tabbed window with a modifer. Might it be a good idea to "disable" the [ ] Middle-click or control-click of links in a web page and the [ ] Middle-click or control-click of bookmarks in the personal toolbar items options?
For myself and (I suspect) lots of Mac users, control-click is *not* a substitute for click-hold. Click-hold is a one-handed operation, and much preferred. I'm not sure what you want to disable, but for me, click-hold to open a link in a new tab is great; so is manipulation of bookmarks in the sidebar. I certainly hope these do not get disabled.
Isaac, I am a Mac user... mainly 10.x and with Mozilla on 10.x control-click will not work... thus it should be disabled for the carbon builds. Using build 2001102605 with a new profile and control-clicking turned on... click on a link on www.mozilla.org/start nothing.... I would LOVE if this worked... but since it does not it should be disabled by graying out the control-click options.
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: