All users were logged out of Bugzilla on October 13th, 2018
Build ID: 2001-09-19-05-0.9.4 Reproducible: Always Steps: 1. Install a daily branch build with QuickLaunch enabled. 2. Launch the browser, play for a while, notice bad UI elements, get another build. 3. Install another daily branch build, into a seperate directory Results: It appears QuickLaunch is launching the older build, instead of the new one I have installed. Why do I think this? Because it exhibits different behavior, from between, the new build launched from the short cut on my desktop, and the what looks like the previous build. Note: This could affect people testing the QuickLaunch feature.
Did you exit the program (including QuickLaunch) before running the installer? If not, did the installer fail to detect the running version? How is QuickLaunch running after the install?
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Answer to Peter's questions: 1) Did you exit the program (including QuickLaunch) before running the installer? - Yes. 2) If not, did the installer fail to detect the running version? - I think the installer can detect between versions, like 6.0 and 6.1, but may be having problems between intra-version detection of daily builds. 3) How is QuickLaunch running after the install? Selected, QuickLaunch to be on in install dialogue. Note: QuickLaunch also running after a reboot, irrespective if I exit or disable it. Filed Bug 101144.
See also bug 89781, [rfe] make quick launch compare versions before using existing process. That covers the case of using zip builds instead of installer builds, and would also be good for QA wanting to quickly switch between two different builds.
Not likely to affect the vast majority of nsbranch users: nsbranch-
Keywords: nsbranch → nsbranch-
Trying to reproduce using 2001-10-22-06-trunk and 2001-10-29-06-trunk builds but not having any success. I install 10-22-06 first, then 10-29-06 (in a different folder) and don't have any mixups. If there's any other info on how to reproduce, I'm all ears.
Marking p3 and mozilla1.1, will move in once I can reproduce
Priority: -- → P3
Target Milestone: --- → mozilla1.1
-> default assignee
Assignee: pchen → trudelle
QA Contact: tpreston → sairuh
Target Milestone: mozilla1.1 → ---
Target Milestone: --- → Future
what is the reason we are futuring this one?
How many users have multiple builds?
Even with multiple builds, this is difficult for developers to reproduce.
Quicklaunch is done based on: Bug 383161 – keep in memory (turbo mode?) for faster startup not working so this one should be WONTFIX I guess.
Assignee: trudelle → jag
Priority: P3 → --
QA Contact: bugzilla
Target Milestone: Future → ---
(In reply to comment #13) > Quicklaunch is done based on: Bug 383161 – keep in memory (turbo mode?) for > faster startup not working > > so this one should be WONTFIX I guess. Which in turn is a duplicate of: Bug 361682 - Remove "turbo mode" from suiterunner builds
=> WONTFIX - turbo is gone after SM v1.1
Status: NEW → RESOLVED
Last Resolved: 10 years ago
QA Contact: ui-design
Resolution: --- → WONTFIX
Assignee: jag-mozilla → nobody
Component: UI Design → QuickLaunch (AKA turbo mode)
Product: SeaMonkey → Core
QA Contact: ui-design → quicklaunch
Component: QuickLaunch (AKA turbo mode) → QuickLaunch (AKA turbo mode)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.