Closed Bug 582257 Opened 15 years ago Closed 15 years ago

Feedback in 4.0 beta told me I wasn't part of the beta program

Categories

(Input :: General, defect, P2)

Product:
Input
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: dspectar, Assigned: wenzel)

References

Details

(Whiteboard: [Input])

Attachments

(2 files)

Screen shot showing that Firefox 4 beta 2 is not allowing me to leave feedback.
39.57 KB, image/png
Details
Screen shot showing that Firefox 4 beta 2 is somehow not reporting the correct version on my system.
30.21 KB, image/png
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 When I clicked on the feedback button in Firefox 4 beta 1 to report a problem "I'm sad", it took me to the URL for reporting issues. However, the URL reported to me that I wasn't a member of the beta program. I found that strange since I was accessing the browser from Firefox 4 beta 1. (I've since uninstalled it in order to report this to you from firefox 3.6.) Reproducible: Always Steps to Reproduce: 1. Launch Firefox 4.0 beta 1 2. Press Feedback button 3. Say "I'm Sad" Actual Results: The page reports that you must be part of the beta program to report an issue Expected Results: The page should allow me to report an issue
Type about: in the address bar. The last line should be the build identifier please copy and paste that line into the bug.
This also happened to me, and recently - I was able to file "I'm Happy" or "I'm Sad" comments before today. I'm on Windows XP. Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1 ( .NET CLR 3.5.30729; .NET4.0E)
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1
This is because beta 2 is being released today and the feedback site already thinks you are not running the latest beta. Once the upgrades get rolled out it'll work, but I think the feedback site should be more forgiving.
Build identifier: Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b2) Gecko/20100720 Firefox/3.0.10 NET_mmhpset (.NET CLR 3.5.30729) I am using the latest beta, as far as I can tell, but this is still always happening to me. The feedback site tells me I need the latest version and offers a link to download it. This link takes me to a site that, from what I can tell, offers a download of what I'm already using.
This appears to be fixed for me using 4.0b2. Build identifier: Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b2) Gecko/20100720 Firefox/4.0b2 ( .NET CLR 3.5.30729; .NET4.0E)
Upon looking at Travis' above comment and comparing his build identifier to mine, it would appear that my Firefox 4 beta 2 is reporting the wrong version for some reason. I am positively certain that I am running Firefox 4 beta 2. It makes no sense for Firefox 3.0.10 to be using Gecko 2.0b2.
Comment on attachment 462096 [details] Screen shot showing that Firefox 4 beta 2 is not allowing me to leave feedback. The "latest Firefox Beta" link directs me to a download of the version I am currently using.
Attachment #462096 - Attachment description: Screen shot showing that Firefox 4 beta 2 is somehow not reporting the correct version on my system. → Screen shot showing that Firefox 4 beta 2 is not allowing me to leave feedback.
This is also occurring for me. Windows 7 Professional 64 bit. Build identifier: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b2) Gecko/20100720 Firefox/4.0b2
Component: General → Input
Product: Firefox → Webtools
QA Contact: general → input
Version: unspecified → 1.6
Same issue here Build identifier: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b2) Gecko/20100720 Firefox/4.0b2
Might be a caching issue. I was able to reproduce this a few minutes ago, but it's not consistent. The 301 redirect seems to be delivered with a Vary: Accept-Language but not Vary: User-Agent. Might be cached in the frontend cached because of that. Hmmm.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
I believe this has to do with Beta 3 being in the process of release.
Severity: critical → normal
OS: Windows 7 → All
Hardware: x86 → All
Summary: Feedback in 4.0 beta 1 told me I wasn't part of the beta program → Feedback in 4.0 beta told me I wasn't part of the beta program
I agree with comment #4 that we need to be more forgiving or at least message out on that download beta page that a new beta is soon to be released. I'll have a patch with new text sometime tomorrow, Fred.
Priority: -- → P2
Target Milestone: --- → 1.6.2
It happened very consistently for me on one machine. Never worked once. It may be related to having multiple versions of firefox, as that's the case for the computer I'm reporting.
And it is certainly not because the server is confused about what version of the beta is the latest. I have clearly demonstrated that my firefox beta2 has been reporting itself as the wrong version since day 1. Please see the attached screenshots.
Bruno your user agent is mangled. Your issue is different than all the other reporters here. These people have hit this error because they tried to use the feedback form on the cusp of a new release. typing about:config in the address bar and filtering on useragent right click on any bold entries and choose reset. Should fix your case.
Assignee: nobody → fwenzel
Severity: normal → critical
Priority: P2 → P1
I can't pinpoint where this is coming from just yet. It works at the moment in production, including Vary:User-Agent headers. I am wondering if there is some faulty input that results in the redirect being cached, thus serving the redirect to valid UAs for some time afterwards.
Severity: critical → major
Priority: P1 → P2
Looking at this in svn, can we parse for the release date time next to the latest beta and block if that date is later than the current day, Fred?
But does that even make sense? If 4.0b3 is considered the latest beta, then allowing *even later* releases (read: minefield) is already enabled. Only older versions (read: 4.0b2) will not work.
I am having the same problem and i even reinstalled it (I didn't uninstall before i reinstalled it. Has someone tried that?) Im going to try disabling it and turning it back on.
(In reply to comment #28) > I am having the same problem and i even reinstalled it (I didn't uninstall > before i reinstalled it. Has someone tried that?) Im going to try disabling it > and turning it back on. my stuff is Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b2) Gecko/20100720 Firefox/4.0b2 btw
I think we've identified the issue. In r71989, Firefox 4.0b3 was marked "current" a few days before its release. Firefox Input picks this up and locks out any older version of Firefox from leaving feedback. (CCing Pascal so he's aware of the problem). There are two options I can think about: 1) do not mark a version as latest that hasn't been released, and mark this bug WFM As a rule of thumb, changing that data before the release is also likely to break any third-party sites that rely on the data being accurate. 2) use the Firefox version *history* library to determine the latest released version. After a new version was added, give a grace period of 1 day (or more?) for people to give more feedback even with the second to last version. I am leaning towards 1), as in my understanding the LATEST_VERSION variables should be changed as part of the release process, but if we have a reason for the more complicated logic in 2), I could code that up too. Opinions?
I see comments about 4b3 being marked available and that is why the 4b2 Feedback doesn't work. This really means nothing unless yopu can download 4b3 which doesn't seem to be the case if you go to the download page. That is poor version management to require something you can't get. I guess that is one way to cuyt down on negative comments.
This is an answer from Pascal on IRC: pascalc: I'd guess because you pull up from the latest revision instead of a specific revision of product-details [1:05pm] pascalc: here is how you should include it to point to 4.0b2: [1:05pm] pascalc: product-details -r71411 http://svn.mozilla.org/libs/product-details [1:07pm] pascalc: if you don't have the revision number mentioned, you are pulling HEAD which contains the ongoing work for the various staging servers were we prepare releases
Sorry, but that makes little sense. If I have to retag manually every time a release comes out, we might as well hardcode the release version itself. It does seem like we need a new field then, LATEST_RELEASED_BETA_VERSION or something?
Whiteboard: [Input]
I am using this new variable to determine the latest released version now: http://github.com/fwenzel/reporter/commit/ab0bcca
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(In reply to comment #19) > Bruno your user agent is mangled. Your issue is different than all the other > reporters here. These people have hit this error because they tried to use the > feedback form on the cusp of a new release. > > typing about:config in the address bar and filtering on useragent right click > on any bold entries and choose reset. Should fix your case. Thanks for the clarification and help, Kevin.
Component: Input → General
Product: Webtools → Input
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: