Closed Bug 1039904 Opened 5 years ago Closed 5 years ago
Changing the URL in a pinned tab opens new tab instead
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? I suspect it's caused by an extension.  https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
Not only am I able to reproduce it in safe-mode, but also with a new profile. STR.  open several tabs add some app-tabs(eg. http://planet.mozilla.org/?abc )  set session-restore to >Show my windows and tabs from last time<  restart browser.  change url of app-tab to http://planet.mozilla.org/?abcdef result: instead of simply opening the url, Nightly opens a new tab, at the end of the tab-strip.
The last working mozilla-central build is from 2014-07-11(rev:e1a037c085d1), the next one (rev: b0701d069bf9), at least for me, doesn't.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
[Tracking Requested - why for this release]: This was merged up yesterday, and is a recent regression of core functionality. http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1a037c085d1&tochange=b0701d069bf9 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...)
(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 ? yes
Assignee: nobody → dao
Points: --- → 2
OS: Mac OS X → All
Hardware: x86 → All
Waiting on feedback from GMC if this bug should be added.
Iteration: 34.1 → ---
(I think we should test-suite this so we don't regress it again)
Added to Iteration 34.1. Dao, can you mark this bug as either [qa+] or [qa-] for verification.
Status: NEW → ASSIGNED
QA Whiteboard: [qa?]
QA Whiteboard: [qa?] → [qa+]
Why was this caused by bug 1034845?
(In reply to :Gavin Sharp [email: email@example.com] 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.
Attachment #8465478 - Flags: review?(mconley) → review+
Comment on attachment 8465478 [details] [diff] [review] patch 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.
Status: ASSIGNED → RESOLVED
Closed: 5 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.
Status: RESOLVED → VERIFIED
QA Whiteboard: [qa+] → [qa!]
Comment on attachment 8465478 [details] [diff] [review] patch Approval Request Comment [Feature/regressing bug #]: bug 1034845 [User impact if declined]: see comment 0 [Describe test coverage new/current, TBPL]: https://tbpl.mozilla.org/?rev=e3e739ad7b55 [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.
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.