515932 - loadOneTab and addTab should accept a hash of parameters, including a parameter for opening the tab next to the current one

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Dão Gottwald [:dao]]

Attachment: patch

For bug 515635, we need a way to open a tab next to the current one without sending the referrer.

Instead of just adding that parameter, I propose we also accept a hash of parameters, as the number of parameters is getting unreasonable and most callers just need a subset of them. That way, we can happily add more parameters without fearing that, if we added a tenth parameter that many callers would want to use, they would also have to set the eight previous parameters, even though they are optional.

So in bug 515635, instead of:

gBrowser.loadOneTab(submission.uri.spec, null, null, submission.postData, null, false, true);

... we'd do:

gBrowser.loadOneTab(submission.uri.spec, {postData: submission.postData, relatedToCurrent: false});

... which is easier to write, read and maintain.

Comment 1

[Dão Gottwald [:dao]]

(In reply to comment #0)
> gBrowser.loadOneTab(submission.uri.spec, {postData: submission.postData,
> relatedToCurrent: false});

this was meant to be relatedToCurrent: true

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 400014 [details] [diff] [review]
patch

I like it. Why add the  explicit aRelatedToCurrent parameter, though?

Comment 3

[John Morkel]

Dão, This patch is similar to Simon Bünzli's patch from bug 465673 of adding another parameter to addTab, which you yourself thought to be complicating things (bug 465673 comment #84).

While this adds the argument in a hash, which is better than just adding more arguments, surely the implied relationship from setting aReferrerURI covers this?

This bug makes the fixes in bug 514310 and bug 465673 redundant to some extent. In short, an extra parameter isn't needed if a referrer can convey the same information. It seems more consistent to use the referrer in this case as it is with middle-clicking or ctrl-clicking.

Comment 4

[Dão Gottwald [:dao]]

(In reply to comment #3)
> Dão, This patch is similar to Simon Bünzli's patch from bug 465673 of adding
> another parameter to addTab, which you yourself thought to be complicating
> things (bug 465673 comment #84).

The extra parameter is redundant when there's a referrer. And the number of parameters is inconvenient, but the ability to pass a hash addresses this.

> While this adds the argument in a hash, which is better than just adding more
> arguments, surely the implied relationship from setting aReferrerURI covers
> this?

Because we don't want to send a referrer to google in the case of bug 515635.

Comment 5

[Dão Gottwald [:dao]]

Attachment: without an explicit aRelatedToCurrent

Comment 6

[Mike Connor [:mconnor]]

Comment on attachment 400089 [details] [diff] [review]
without an explicit aRelatedToCurrent

Yeah, let's go with this one.  I'm a fan.

Can we file a followup to change our existing callers to use this instead?  That way, extensions copying our code will do the better thing, and we can work on deprecating the giant bundle-o-params list in the future from a better place.

Comment 7

[Mike Connor [:mconnor]]

We should also update MDC docs for this.

Comment 8

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/0137837043e0

Comment 9

[[not reading bugmail]]

> +                                  ownerTab: owner,

Should this be aOwner like below?

> +              aOwner                = params.ownerTab;

Comment 10

[Dão Gottwald [:dao]]

No, aOwner isn't declared in the former case, but owner is.

Comment 11

[John Morkel]

Should loadURI or loadURIWithFlags also take a hash of the parameters for consistency?

loadURI takes 3 parameters and loadURIWithFlags takes 5.

Comment 12

[Johnathan Nightingale [:johnath]]

Comment on attachment 400089 [details] [diff] [review]
without an explicit aRelatedToCurrent

Safe on its own, baking for most of a month and, while not exactly blocking bug
514327 (a P1 blocker), makes it substantially easier to land. a=me.

Dao - assuming you're the one landing these - please land them together with bug 514327 so that any regressions caused are clearly associated with the P1 blocker, and they get the appropriate level of immediate attention. In the future, if we need N patches to land a bug, please provide a single rollup patch to approve?

Comment 13

[Dão Gottwald [:dao]]

This and bug 516603 aren't part of bug 514327, they just happen to touch the same code.

Comment 14

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/37b404e0f228

Comment 15

[Eric Shepherd [:sheppy]]

Documentation updated:

https://developer.mozilla.org/en/XUL/Method/addTab
https://developer.mozilla.org/en/XUL/Method/loadOneTab

And this change is listed on the Firefox 3.6 overview page.

Comment 16

[Dão Gottwald [:dao]]

This signature doesn't exist:
addTab( URL, referrerURI, charset, postData, owner, allowThirdPartyFixup, relatedToCurrent )

It's either:
addTab( URL, referrerURI, charset, postData, owner, allowThirdPartyFixup )

Or:
addTab( URL, {referrerURI: ..., charset: ..., postData: ..., inBackground: ..., allowThirdPartyFixup: ..., relatedToCurrent: ...}), whereas all keys (referrerURI, charset, ...) are optional and the order doesn't matter.

Comment 17

[Eric Shepherd [:sheppy]]

Hm, that's non-obvious from the patch. I have no idea at all how to document that given our current documentation format. I'll have to think about that one.

Comment 18

[Dão Gottwald [:dao]]

(In reply to comment #16)
> addTab( URL, {referrerURI: ..., charset: ..., postData: ..., inBackground: ...,
> allowThirdPartyFixup: ..., relatedToCurrent: ...})

I copied this from the wrong method. inBackground is for loadOneTab. addTab has the ownerTab key instead.

Comment 19

[Eric Shepherd [:sheppy]]

I fixed these.

Comment 20

[Dão Gottwald [:dao]]

Perfect, thanks.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed based on check-ins and passed tests on trunk and 1.9.2.