Closed Bug 417421 Opened 14 years ago Closed 14 years ago

Loss of back forward buttons when switching between 1.8 and 1.9

Categories

(Firefox :: Toolbars and Customization, defect, P3)

defect

Tracking

()

VERIFIED FIXED
Firefox 3 beta5

People

(Reporter: pavlov, Assigned: dao)

References

Details

(Keywords: verified1.8.1.13)

Attachments

(3 files, 2 obsolete files)

Say I have a profile that I run with 1.8, now when I run with 1.9 and go back my back/forward buttons are gone.
Gavin/Dao: is this due to the changes we made to the navigation toolbar? I suspect so. How hard would it be to allow the downgrade scenario, or at least, not leave people without back/forward buttons?

I worry a little about the "try Firefox 3, go back to Firefox 2" scenario, here.
Flags: blocking-firefox3?
Duplicate of this bug: 417398
This happens if you customize your toolbar while you're on 1.9.
I'll work on making customizing backwards-compatible.
Assignee: nobody → dao
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Blocks: 394046, 415099
Attached patch support downgrading (obsolete) — Splinter Review
Can we land something similar on branch? Otherwise we'll lose the unified button if you go back to branch, customize, and go forward to trunk again.
Attachment #303303 - Flags: review?(gavin.sharp)
Target Milestone: --- → Firefox 3 beta4
Flags: wanted1.8.1.x?
added a semicolon
Attachment #303303 - Attachment is obsolete: true
Attachment #303369 - Flags: review?(gavin.sharp)
Attachment #303303 - Flags: review?(gavin.sharp)
Flags: blocking1.8.1.13?
Flags: blocking-firefox3? → blocking-firefox3+
Duplicate of this bug: 418395
Duplicate of this bug: 417964
Flags: wanted1.8.1.x?
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.13?
Flags: blocking1.8.1.13+
Attachment #303369 - Flags: review?(gavin.sharp) → review+
Checking in browser/base/content/browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v  <--  browser.js
new revision: 1.973; previous revision: 1.972
done
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Attached patch branch patchSplinter Review
Attachment #305153 - Flags: review?(gavin.sharp)
Attachment #303369 - Attachment description: support downgrading → support downgrading (checked in)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Priority: -- → P3
Target Milestone: Firefox 3 beta4 → Firefox 3
Duplicate of this bug: 420861
Too late for 1.8.1.13 given lack of trunk landing. If you decide we're really doing this on the trunk please nominate for 1.8.1.14
Flags: blocking1.8.1.13+ → blocking1.8.1.13-
Attachment 303369 [details] [diff] has landed on trunk.
Attachment 305153 [details] [diff] isn't supposed to land on trunk.
Attachment 305154 [details] [diff] is an optimization for the migration code which makes sense only once the branch patch is live.
Flags: blocking1.8.1.14?
Gavin tells me that this patch is somehow related to our decision to move the home button, which is a change we are most likely going to backtrack on.

So let this be the definitive statement: Firefox 3 final *will* have the keyhole by default, but will also have the home button on the main navigation toolbar.
Attachment #305153 - Flags: review?(gavin.sharp) → review+
Attachment #305153 - Flags: approval1.8.1.14?
Attachment #305153 - Flags: approval1.8.1.13?
Comment on attachment 305154 [details] [diff] [review]
on trunk, don't add unified-back-forward-button if it's already there (due to the change on branch)

>Index: browser/components/nsBrowserGlue.js

>+          target = target.replace(/(?:^|,)home-button(?:$|,)/, ",");

>+        if (target && !/(?:^|,)home-button(?:$|,)/.test(target))

Assign this regexp to a variable (hasHomeButton?)?
Attachment #305154 - Flags: review?(gavin.sharp) → review+
Attachment #305154 - Attachment is obsolete: true
Comment on attachment 305153 [details] [diff] [review]
branch patch

Approved for 1.8.1.13, a=ss for release-drivers.

Please land ASAP as our code freeze is tonight at 11:59pm PST.
Attachment #305153 - Flags: approval1.8.1.14?
Attachment #305153 - Flags: approval1.8.1.13?
Attachment #305153 - Flags: approval1.8.1.13+
(In reply to comment #18)
> Please land ASAP as our code freeze is tonight at 11:59pm PST.

Will land tonight. :)
Checking in browser/components/nsBrowserGlue.js;
/cvsroot/mozilla/browser/components/nsBrowserGlue.js,v  <--  nsBrowserGlue.js
new revision: 1.72; previous revision: 1.71
done
Target Milestone: Firefox 3 → Firefox 3 beta5
MOZILLA_1_8_BRANCH

Checking in browser/base/content/browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v  <--  browser.js
new revision: 1.479.2.220; previous revision: 1.479.2.219
done
Status: ASSIGNED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Verified.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13pre) Gecko/20080310 BonEcho/2.0.0.13pre ID:2008031003

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre ID:2008031004
Status: RESOLVED → VERIFIED
Duplicate of this bug: 422116
I forgot to set verified1.8.1.13 yesterday.
Duplicate of this bug: 422154
Duplicate of this bug: 422377
Duplicate of this bug: 424771
Duplicate of this bug: 425871
I'm not about to reopen this bug but I'm not sure that's a sufficient fix.  Here's my problem: I have all my navigation buttons in my menu toolbar... so I have everything in one line, address bar, search bar, menu.  Moving from .13 to Minefield still makes the back/forward buttons disappear.  Doubly annoying because they don't show up in Toolbars>Customize, they get dumped in the (hidden) navigation toolbar.

Having it set up correctly in Minefield and then moving to 2.0.0.13 still makes the back/forward buttons disappear.
Cww, could you please file a new bug?
I did: Bug 426026 
Duplicate of this bug: 427377
Duplicate of this bug: 429613
Flags: blocking1.8.1.15?
Duplicate of this bug: 432387
Duplicate of this bug: 433446
You need to log in before you can comment on or make changes to this bug.