it seems to be impossible to use bugzilla without cookies enabled, but the bugzilla pages doesn't tell the user so. it lets the user fill in the data, then displays the login page again. the bug report never makes it into the system (but bugzilla doesn't even tell the user that it won't!) silent failure is discouraging! suggested fix: - tell the user to enable cookies (and to configure their junkbuster to let them through) or - change bugzilla to not rely on cookies (e.g. by using hidden form params instead)
Product -> Bugzilla
Component: Browser-General → Documentation
Product: Browser → Bugzilla
Version: other → 2.15
The bug's author also gave an example of how to configure junkbuster (an http proxy that blocks cookies, among other things) to allow cookies for a bugzilla sight: <rj> ddk: the config is trivial: echo mozilla.org >> cookiefile
Assignee: asa → barnboy
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: doronr → matty
Bugzilla doesn't require cookies - it will just require you to log in every time you need to. If there is a case where cookies are required, then thats a bug (the one with creating an attachment requiring cookies has been fixed in CVS)
Moving out of docs, this is a user interface issue. The login page needs to state that you need cookies enabled for Bugzilla to remember your login past the next page.
Assignee: barnboy → myk
Severity: normal → enhancement
Component: Documentation → User Interface
OS: Linux → All
Hardware: PC → All
Summary: hint to enable cookies or don't require them → login page should state that you need cookies enabled for bugzilla to remember your login past the next page
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18
The User Interface component now belongs to Gerv. Reassigning all UNCONFIRMED and NEW (but not ASSIGNED) bugs currently owned by Myk (the previous component owner) to Gerv.
Assignee: myk → gerv
Reassigning back to Myk. That stuff about Gerv taking over the User Interface component turned out to be short-lived. Please pardon our confusion, and I'm very sorry about the spam.
Assignee: gerv → myk
Eric was bitten by this yesterday while uploading to bug 220724. Has anybody considered a good approach to solve this?
Yeah, but it doesn't it make sense to let the user know that cookies enabled will avoid him having to log in 50 times a day (offtopic wink to bz)?
Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
I think we should try and do this - something like: (Note: you should make sure cookies are enabled for this site. Otherwise, you will frequently be required to re-login.) Gerv
Severity: enhancement → minor
Target Milestone: Bugzilla 2.20 → Bugzilla 2.18
Created attachment 144169 [details] [diff] [review] Patch v.1 This adds the appropriate text to the login template. Gerv
Assignee: myk → gerv
Status: NEW → ASSIGNED
Attachment #144169 - Flags: review?(justdave)
There's a problem I hadn't realized before: the user may be forced to relogin multiple times for other reasons apart from his browser having cookies disabled: site misconfiguration (a common FAQ) and rotating proxies. In that case this error message will hinder more than help.
It's true that there are other things which can cause this. But that doesn't stop the message from being true :-) It doesn't say, for example, "If you are frequently required to log in, make sure cookies are enabled." That would be wrong. Gerv
Attachment #144169 - Flags: review?(justdave) → review+
Fixed. Checking in template/en/default/account/auth/login.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/auth/login.html.tmpl,v <-- login.html.tmpl new revision: 1.6; previous revision: 1.5 done Gerv
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.