Bug 1749107 - firefox does run with old profile after upgrade to F31
Summary: firefox does run with old profile after upgrade to F31
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: 1749441 F31BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2019-09-04 22:08 UTC by Zbigniew Jędrzejewski-Szmek
Modified: 2019-09-10 01:21 UTC (History)
17 users (show)

Fixed In Version: firefox-69.0-2.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1749441 (view as bug list)
Environment:
Last Closed: 2019-09-10 01:21:08 UTC


Attachments (Terms of Use)

Description Zbigniew Jędrzejewski-Szmek 2019-09-04 22:08:32 UTC
Description of problem:

I upgraded my system from F30 to F31 today (no updates-testing).
firefox-wayland refuses to start saying
"You've launched an older version of Firefox" and offers
either "Create New Profile" or "Quit". If a new is created, it
runs OK with this profile.

The upgrade was:
    Upgrade firefox-68.0.2-1.fc31.x86_64     @fedora
    Upgraded    firefox-68.0.2-1.fc30.x86_64 @@System
so the version didn't go down.


Version-Release number of selected component (if applicable):
firefox-68.0.2-1.fc31.x86_64

How reproducible:
I tried a few times, and the error is always the same.

Comment 1 Zbigniew Jędrzejewski-Szmek 2019-09-05 08:13:10 UTC
With firefox-69.0-2.fc31.x86_64, the issue is gone. I guess this can be closed as soon as firefox-69 is submitted as update.

Comment 2 Martin Stransky 2019-09-05 08:45:53 UTC
Yes, I disabled that for firefox-69.0-2 release.

Comment 3 Kamil Páral 2019-09-05 11:21:12 UTC
Martin, why is this happening? The current F30 and F31 version are completely the same. Why does Firefox claim that the F30 version is newer?

As for the current fix, I assume it is this:
https://src.fedoraproject.org/rpms/firefox/c/b2802deb3dc56b6e8818a5b565414004377e6cdd?branch=master
Is it a good idea to just disable the warning dialog? That can burn us in the future. Also, there is a reason why the warning dialog is there - to protect user data. If we disable the protection, people can mess up their profiles by switching between Fedora-provided Firefox and external ones.

I propose this problem as a Beta blocker, because of the following criteria:
"For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed. "
"The upgraded system must meet all release criteria."
https://fedoraproject.org/wiki/Fedora_31_Beta_Release_Criteria#Upgrade_requirements
"It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments. "
https://fedoraproject.org/wiki/Basic_Release_Criteria#Required_applications

Comment 4 Martin Stransky 2019-09-05 11:49:04 UTC
(In reply to Kamil Páral from comment #3)
> Martin, why is this happening? The current F30 and F31 version are
> completely the same. Why does Firefox claim that the F30 version is newer?

Because build-time is used as a criteria which may differ for various builds.
As we distribute the same Firefox versions on all Fedoras we're safe here.

> As for the current fix, I assume it is this:
> https://src.fedoraproject.org/rpms/firefox/c/
> b2802deb3dc56b6e8818a5b565414004377e6cdd?branch=master
> Is it a good idea to just disable the warning dialog? That can burn us in
> the future. Also, there is a reason why the warning dialog is there - to
> protect user data. If we disable the protection, people can mess up their
> profiles by switching between Fedora-provided Firefox and external ones.

If you install Firefox binaries from Mozilla you're expected to know what you're doing
and you should create a new profile for it.
Also Mozilla builds have the profile check active.

> I propose this problem as a Beta blocker, because of the following criteria:
> "For each one of the release-blocking package sets, it must be possible to
> successfully complete a direct upgrade from a fully updated, clean default
> installation of each of the last two stable Fedora releases with that
> package set installed. "
> "The upgraded system must meet all release criteria."
> https://fedoraproject.org/wiki/
> Fedora_31_Beta_Release_Criteria#Upgrade_requirements
> "It must be possible to run the default web browser and a terminal
> application from all release-blocking desktop environments. "
> https://fedoraproject.org/wiki/Basic_Release_Criteria#Required_applications

I'm not sure what problem - the check is here or the check is disabled?

Also frozen Fedora Beta image can contain older Firefox version than any fully
up to date Fedora release if new Firefox version is released after
Fedora Beta release.

Comment 5 Zbigniew Jędrzejewski-Szmek 2019-09-05 12:55:53 UTC
Ideally, firefox would use a version comparison. Looking at build time
is only useful for upstream (and even there it's questionable, because they
do have e.g. nightly builds and non-nightly builds and things are not always
built strictly chronologically). In a scenario where people might installs builds
with different versions from different sources, or where stable point upgrades are
built, a check based on build time is not useful at all.

Comment 6 Kamil Páral 2019-09-05 13:23:46 UTC
As Zbigniew mentioned above, build-time comparison is really silly. If that can't be easily changed, I agree that we can't do much but to disable the downgrade protection (and ideally request changes upstream).

> I'm not sure what problem - the check is here or the check is disabled?

That blocker proposal is not related to the rest of our discussion. This bug is proposed as a blocker, because currently when you upgrade F30 to F31, your Firefox won't start properly. That will be fixed once firefox-69.0-2 is stable in F31. For that you need to go through Bodhi, and since we're currently frozen, you either need a blocker or a freeze exception approval. Thus this proposal :)

Comment 7 Martin Stransky 2019-09-05 15:47:12 UTC
Yes, the version check sounds reasonable, I'll file a new bug for it.

Comment 8 Martin Stransky 2019-09-05 15:50:00 UTC
(In reply to Martin Stransky from comment #7)
> Yes, the version check sounds reasonable, I'll file a new bug for it.

Filed as Bug 1749441.

Comment 9 Fedora Update System 2019-09-06 10:59:55 UTC
FEDORA-2019-f91860efa3 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f91860efa3

Comment 10 Kalev Lember 2019-09-06 11:00:21 UTC
I edited the firefox update to mark this bug as fixed.

Comment 11 Adam Williamson 2019-09-06 16:09:07 UTC
+1 blocker per Basic criterion "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments" and Beta criterion "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed...The upgraded system must meet all release criteria."

Comment 12 Jared Smith 2019-09-06 19:50:24 UTC
+1 blocker for the same reasons as Adam in comment 11.

Comment 13 Geoffrey Marr 2019-09-09 19:05:54 UTC
Discussed during the 2019-09-09 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criterion:

"upgraded systems must meet release criteria" criterion combined with the "desktop browser must work"

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-09/f31-blocker-review.2019-09-09-16.00.txt

Comment 14 Fedora Update System 2019-09-10 01:21:08 UTC
firefox-69.0-2.fc31, nspr-4.22.0-1.fc31, nss-3.46.0-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.