Changing the URL in a pinned tab opens new tab instead

VERIFIED FIXED in Firefox 33



Tabbed Browser
4 years ago
4 years ago


(Reporter: matthias koplenig, Assigned: dao)



33 Branch
Firefox 34
Dependency tree / graph
Bug Flags:
firefox-backlog +
in-testsuite +

Firefox Tracking Flags

(firefox33+ verified, firefox34 verified)



(1 attachment)



4 years ago
For the last few Nightlies I have been unable to change the URL in an App-tab, instead a new tab is created at the end of the Tabstrip.

Even pressing Enter, without changing the URL opens a new tab.
I can't reproduce this on today's Nightly on OS X. Can you try reproduce this in safe mode[1]? I suspect it's caused by an extension.

Flags: needinfo?(mozilla)

Comment 2

4 years ago
Not only am I able to reproduce it in safe-mode, but also with a new profile.

[1] open several tabs add some app-tabs(eg. )
[2] set session-restore to >Show my windows and tabs from last time<
[3] restart browser.
[4] change url of app-tab to

result: instead of simply opening the url, Nightly opens a new tab, at the end of the tab-strip.
Flags: needinfo?(mozilla)

Comment 3

4 years ago
The last working mozilla-central build is from 2014-07-11(rev:e1a037c085d1), the next one (rev: b0701d069bf9), at least for me, doesn't.


4 years ago
Summary: Changing the URL in App-Tab opens new Tab instead → Changing the URL in a pinned tab opens new tab instead
Confirmed in 33.0a1 (2014-07-20), Win 7 using the STR in comment 2
Ever confirmed: true

Comment 5

4 years ago
[Tracking Requested - why for this release]: This was merged up yesterday, and is a recent regression of core functionality.

The best I can think of here is bug 1034845... Dão, is it just me or would this be caused by the loadURI vs. openUILinkIn switch in loadCurrent in urlbarBindings.xml ? (not entirely sure why yet, but it seems plausible...)
status-firefox33: --- → affected
status-firefox34: --- → affected
tracking-firefox33: --- → ?
Flags: needinfo?(dao)
Flags: firefox-backlog+
Keywords: regression

Comment 6

4 years ago
(In reply to :Gijs Kruitbosch (PTO july 17-21) from comment #5)
> The best I can think of here is bug 1034845... Dão, is it just me or would
> this be caused by the loadURI vs. openUILinkIn switch in loadCurrent in
> urlbarBindings.xml ?

Assignee: nobody → dao
Blocks: 1034845
Points: --- → 2
Flags: needinfo?(dao)
OS: Mac OS X → All
Hardware: x86 → All


4 years ago
Iteration: --- → 34.1
Waiting on feedback from GMC if this bug should be added.
Iteration: 34.1 → ---

Comment 8

4 years ago
(I think we should test-suite this so we don't regress it again)
Flags: in-testsuite?
Iteration: --- → 34.1
Added to Iteration 34.1.  Dao, can you mark this bug as either [qa+] or [qa-] for verification.
QA Whiteboard: [qa?]
Flags: needinfo?(dao)


4 years ago
QA Whiteboard: [qa?] → [qa+]
Flags: needinfo?(dao)
QA Contact: cornel.ionce


4 years ago
Attachment #8465478 - Flags: review?(mconley)
Why was this caused by bug 1034845?
tracking-firefox33: ? → +
Flags: needinfo?(dao)

Comment 12

4 years ago
(In reply to :Gavin Sharp [email:] from comment #11)
> Why was this caused by bug 1034845?

Because it replaced the gBrowser.loadURIWithFlags call with openUILinkIn, to avoid duplicating the flags logic.
Flags: needinfo?(dao)
Attachment #8465478 - Flags: review?(mconley) → review+
Comment on attachment 8465478 [details] [diff] [review]

Review of attachment 8465478 [details] [diff] [review]:

::: browser/base/content/utilityOverlay.js
@@ +219,5 @@
>    var aDisallowInheritPrincipal = params.disallowInheritPrincipal;
>    var aInitiatingDoc        = params.initiatingDoc;
>    var aIsPrivate            = params.private;
>    var aSkipTabAnimation     = params.skipTabAnimation;
> +  var aAllowPinnedTabHostChange = !!params.allowPinnedTabHostChange;

Just a heads up that we'll want to add this to the documentation in the header of this function.
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
QA Contact: cornel.ionce → andrei.vaida
I was able to reproduce the initial issue on older Nightlies 33.0a1 (e.g. 2014-07-14, 2014-07-16), as the reporter mentioned in Comment 0 and 2.

Verified fixed on Nightly 34.0a1 (2014-08-03) using Windows 7 64-bit, Mac OS X 10.9.4 and Ubuntu 14.04 LTS 64-bit.
QA Whiteboard: [qa+] → [qa!]
status-firefox34: affected → verified

Comment 17

4 years ago
Comment on attachment 8465478 [details] [diff] [review]

Approval Request Comment
[Feature/regressing bug #]: bug 1034845
[User impact if declined]: see comment 0
[Describe test coverage new/current, TBPL]:
[Risks and why]: trivial fix, low risk
[String/UUID change made/needed]: none
Attachment #8465478 - Flags: approval-mozilla-aurora?
Attachment #8465478 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified fixed on Aurora 33.0a2 (2014-08-05) as well, using Windows 7 64-bit, Ubuntu 13.04 32-bit and Mac OS X 10.9.4.
status-firefox33: fixed → verified
A test for this was landed in bug 1064280
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.