GM_openInTab should obey Firefox tab option

I'm thinking that openUILinkIn might be a good (better?) solution here also.

We can use it

GM_BrowserUI.openInTab = function(domWindow, url) {
  if (this.isMyWindow(domWindow)) {
var loadInBackground = this.tabBrowser.mPrefs.getBoolPref("browser.tabs.loadInBackground");
openUILinkIn(url, loadInBackground ? "tab" : "tabshifted")
  }
}

While we're at it, GM_openInTab doesn't send the referrer header. Should it also send the referrer if it's enabled (network.http.sendRefererHeader in prefs)? We can't use openUILinkIn to send the referrer, but we can use tabbrowser.addTab or tabbrowser.loadOneTab.

Send referrer header

Museum of modern art moma Child museum in new jersey

http://a-zoloft-side-effects.associates-program.com Zoloft Side Effects http://a-generic-zoloft.associates-program.com Generic Zoloft

http://www12.asphost4free.com/winebar/wine/pg=5.html wine gift http://www12.asphost4free.com/cap4U/bottle-cap/p=10.html bottle cap catcher

http://www12.asphost4free.com/winebar/wine/pg=8.html wine bottle http://www12.asphost4free.com/winebar/wine/pg=9.html wine gift basket

http://www12.asphost4free.com/jumping4U/jumping/bungee-jumping.html bungee jumping http://www12.asphost4free.com/jumping4U/jumping/show-jumping.html show jumping

http://www12.asphost4free.com/allmask/game/free-download-game/yahoo-game-collapse-free-download.html yahoo game collapse free download http://www12.asphost4free.com/allmask/game/free-download-game/free-download-of-nickelodeon-game.html free download of nickelodeon game

http://www12.asphost4free.com/allmask/game/network-game/index.html cartoon network game http://www12.asphost4free.com/allmask/game/network-game/all-nickelodeon-cartoon-network-game.html all nickelodeon cartoon network game

Does open-in-tab usually send the referer header? If so, how does it work. Can we reuse the function that Firefox uses when you click open-in-tab in, for example, the context menu?

Replying to boo..@youngpup.net:

Does open-in-tab usually send the referer header?

Yep, does for me.

If so, how does it work. Can we reuse the function that Firefox uses when you click open-in-tab in, for example, the context menu?

I think you're looking for openUILinkIn. We should be able to. And, bonus: it's got an argument for populating the referer with!

Replying to aranti..@gmail.com:

I think you're looking for openUILinkIn. We should be able to. And, bonus: it's got an argument for populating the referer with!

There's also openNewTabWith(): http://lxr.mozilla.org/mozilla1.8/source/browser/base/content/browser.js#4812 http://lxr.mozilla.org/mozilla1.8/source/toolkit/content/contentAreaUtils.js#56

They look about equivalent to me.

Replying to boo..@youngpup.net:

There's also openNewTabWith(): http://lxr.mozilla.org/mozilla1.8/source/browser/base/content/browser.js#4812

This one appears to be a property of an object related to context menus, with references to "this" that won't work here.

http://lxr.mozilla.org/mozilla1.8/source/toolkit/content/contentAreaUtils.js#56

This one wants an event, which we don't really have at this point.

Replying to aranti..@gmail.com:

Replying to boo..@youngpup.net:

There's also openNewTabWith(): http://lxr.mozilla.org/mozilla1.8/source/browser/base/content/browser.js#4812

This one appears to be a property of an object related to context menus, with references to "this" that won't work here.

I was pointing at the invocation, as an example of how you can pass null for the other args. Whichever seems less coupled to Mozilla internals is good with me.

Both openUILinkIn() and openNewTabWith() use browser method loadOneTab() to open a URL in new tab (see line line 88 and line 227). It has arguments for load in background tab and referrer as well, so why don't we just use loadOneTab() instead?

Because either or both of those methods perform all sorts of logic that we would have to re-implement. Nothing super complex, but it's already done!

I would rather go as high up in the call stack as possible so that we capture as much of the logic as possible that Mozilla does when you click "open in new tab" on a link.

If we re-implement the logic for determining whether to open in the foreground or background, for example, then we will have to update it when Mozilla changes this logic.

OK, I get it now. I think openNewTabWith() is the strong candidate. It's used by "Open in New Tab" on context menu. Also, openUILinkIn() uses pref "browser.tabs.loadBookmarksInBackground" instead of "browser.tabs.loadInBackground".

The second argument in openNewTabWith() is used to set the referrer header and to do a security check of whether the document as allowed to reference the URL (for example, if we click on a chrome link. I found another bug on this with current GM_openInTab()).

Test case:
http://zoolcar9.lhukie.net/test/GM_openInTab.html
http://zoolcar9.lhukie.net/test/GM_openInTab.user.js

Patch follows.

uses openNewTabWith()

Furniture Ashley Furniture Store

江苏省顺利牧业是一家专业从事良种瘦肉型仔猪繁育、仔猪销售的独资企业。基地成立以来，一直深受省、市、县三级领导的关心与扶持，年年被评为诚实、守信企业，全国外三元育种协作组成员单位，经过不断的扩建,和仔猪品种的改良,基地常年面向全国供应25-110斤长白、杜洛克、双肌臀大约克、内 外三元、纯种四元优质瘦肉型苗猪， 养猪基地所有繁育场采用科学节约化繁育管理，技术质量高，抗病能力强、成活率高。目前加盟我公司连锁大型猪场已达50多家，确保质量。 基地主防：口蹄疫、链球菌、蓝耳病、弓形虫猪圆环病毒、二型混合感染等。 目前公司苗猪远销：苏、沪、浙、皖、鄂、赣、豫、湘、京、冀、晋、陕、新、粤、闽以及东北三省，内蒙等地。让每一个客户都能在顺利苗猪繁殖场,买到良种瘦肉型苗猪是公司最根本宗旨！

1、建立外贸型公司，原料、市场、技术、人才、资金、信息等资；

2、利用现代电子信息技术，建立和完善顺利牧业的电子商务系统和计算机管理系统，实现网上的物流管理，网下的配送服务；

8y4oHd 0f9v37f7d2g9flas5

http://opisygg.qqryk.pl/

Replying to boo..@youngpup.net:

Replying to aranti..@gmail.com:

Replying to boo..@youngpup.net:

There's also openNewTabWith(): http://lxr.mozilla.org/mozilla1.8/source/browser/base/content/browser.js#4812

This one appears to be a property of an object related to context menus, with references to "this" that won't work here.

I was pointing at the invocation, as an example of how you can pass null for the other args. Whichever seems less coupled to Mozilla internals is good with me.

can happy am has dont your the fun jet really

Replying to anonymous:

can happy am has dont your the fun jet really

Replying to loucypher.m..@gmail.com:

By default, GM_openInTab(url) command loads the url in a new background tab. It should obey Firefox tab option "When I open a link in a new tab, switch to it immediately", or "browser.tabs.loadInBackground" in prefs.

CHEYENE MAME HAPPE

(: :) HAPPY

Брюэр Джин, Планета Ка-Пэкс

Send the referer from the running tab, not from the selected one

Since FF 3.0.x the patch "GM_openInTab-send_referrer.patch" didn't work probally.

It gives the referer of the selectedtab to the new tab - not the URL from the calling tab (if a greasemonkey script open a link in a tab, that is actually not selected)

I've made a simple patch for this problem: http://greasemonkey.devjavu.com/attachment/ticket/22/GM_openInTab-send_correct_referrer.patch

What's the current status of this ticket?
It seems the topic slided from "following FF open in tab option" to "setting the proper referer". Has the first problem been solved?
What about the second one? Has any maintainer looked into the above proposed patch?

We had #198 in the 0.8.1 milestone, but it's basically a duplicate of this ticket.

Version 0.8.1 is already released, so setting new features with that milestone is counter-productive. (And I see no evidence that #198 was ever related to 0.8.1.)

Replying to aranti..@gmail.com:

Version 0.8.1 is already released, so setting new features with that milestone is counter-productive.

Oops. I haven't really followed release numbers (i'm only using SVN). I picked 0.8.1 because it appeared to be the next milestone in the current roadmap (it still had open tickets, and 0.9 did not seem appropriate). I may have done the same mistake on other tickets during the same session, sorry about that. I'll be more careful about it in the future.
Thanks for pointing it out. :-)

(And I see no evidence that #198 was ever related to 0.8.1.)

I deleted the 0.8.1 milestone for #198 myself yesterday -- as you can check in its last comment. I suppose the author of the ticket had set it in the first place.

Replying to aranti..@gmail.com:

Version 0.8.1 is already released, so setting new features with that milestone is counter-productive.

Oops. I haven't really followed release numbers (i'm only using SVN). I picked 0.8.1 because it appeared to be the next milestone in the current roadmap (it still had open tickets, and 0.9 did not seem appropriate).

By the way, what is the next official milestone? 0.9?

Replying to o.cor..@gmail.com:

By the way, what is the next official milestone? 0.9?

There's nothing "official" as far as I'm aware.

Replying to aranti..@gmail.com:

There's nothing "official" as far as I'm aware.

Shouldn't we set one, if only for ticket management purposes? (i'm trying to highlight what appear to be the most important things to fix, and a milestone tag would definitely help)