Closed
Bug 269294
Opened 20 years ago
Closed 20 years ago
Do not mention QuickSearch in the error message if not in use
Categories
(Bugzilla :: User Interface, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: LpSolit, Assigned: LpSolit)
References
Details
Attachments
(1 file, 3 obsolete files)
1.33 KB,
patch
|
goobix
:
review+
|
Details | Diff | Splinter Review |
When entering a invalid bug number or alias in the page footer (Find bug #), the error message mentions QuickSearch and the fact that JavaScript should be enabled. I misunderstood what QuickSearch was and I thought this textfield in the page footer (Find bug #) *was* the QuickSearch feature, which is of course wrong. I guess most users do not go to the quicksearch.html page and have no idea what we are talking about here. As most of them already have JavaScript enabled, they may not understand why Bugzilla is complaining. What I suggest is to mention QuickSearch only when users submit a query from quicksearch*.html pages.
Assignee | ||
Comment 1•20 years ago
|
||
Assignee: myk → LpSolit
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•20 years ago
|
||
Comment on attachment 165642 [details] [diff] [review] Mention QuickSearch only when appropriate I think this is useful to not confuse users.
Attachment #165642 -
Flags: review?(kiko)
Assignee | ||
Comment 3•20 years ago
|
||
Comment on attachment 165642 [details] [diff] [review] Mention QuickSearch only when appropriate The error message can be simplified a bit. New patch coming...
Attachment #165642 -
Flags: review?(kiko)
Assignee | ||
Comment 4•20 years ago
|
||
Attachment #165642 -
Attachment is obsolete: true
Assignee | ||
Comment 5•20 years ago
|
||
Comment on attachment 165707 [details] [diff] [review] Mention QuickSearch only when appropriate, v2 New attempt... :)
Attachment #165707 -
Flags: review?(kiko)
Assignee | ||
Updated•20 years ago
|
Flags: blocking2.20?
Flags: blocking2.18?
Comment 6•20 years ago
|
||
Sounds good to me. I always hated that error message.
Flags: blocking2.20?
Flags: blocking2.20+
Flags: blocking2.18?
Flags: blocking2.18+
Target Milestone: --- → Bugzilla 2.18
Assignee | ||
Comment 7•20 years ago
|
||
wurblzap just wrote a patch to port QuickSearch to perl, this is bug 70907. Until that bug get closed, we need to hide this error message about QuickSearch, especially for the 2.18 branch. kiko suggested me a simple and clever way to do this for the 2.18 branch where no too huge patches are expected right now. I will first test his idea and submit later if this works. For 2.20, a more complete solution may be investigated, assuming bug 70907 won't be checked in too early. CC'ing wurblzap so he can inform me about what is going on with his patch and the consequences of it.
Depends on: 70907
Assignee | ||
Comment 8•20 years ago
|
||
Here is kiko's suggestion: add the comment about QuickSearch between <noscript> and </noscript> tags. My tests show that quicksearch*.html generate an error message only if JS is disabled. If enabled, these files simply return, in the worst case, an empty list via buglist.cgi. Consequently, the warning about QuickSearch is only pertinent when JS is disabled and these tags above seem very appropriate here! I think 99% of users have JS enabled in their browsers and should never see that part of the error message, which is irrelevant for them. There is still 1% of users who do not have JS enabled and among which a fraction of them do not use quicksearch and so should not get this error message. But this fraction is so small that it could be enough, even for the trunk, to use this very simple solution. Moreover, this error message should disappear as soon as bug 70907 get fixed and maybe it not useful to spend more time on this.
Assignee | ||
Comment 9•20 years ago
|
||
Comment on attachment 166709 [details] [diff] [review] Trivial solution for the 2.18 branch (and maybe the trunk?) Simple fix for the 2.18 branch (and the trunk?)
Attachment #166709 -
Flags: review?(vladd)
Comment 10•20 years ago
|
||
Comment on attachment 166709 [details] [diff] [review] Trivial solution for the 2.18 branch (and maybe the trunk?) This looks good (except its lack of identation).
Attachment #166709 -
Flags: review?(vladd) → review+
Comment 11•20 years ago
|
||
Oooh, I like the latter one, let's go ahead and land it on both. Bug 70907 will have better ways to deal with the situation when it lands.
Assignee | ||
Updated•20 years ago
|
Attachment #165707 -
Attachment is obsolete: true
Attachment #165707 -
Flags: review?(kiko)
Assignee | ||
Comment 12•20 years ago
|
||
Now with the correct indentation.
Attachment #166709 -
Attachment is obsolete: true
Assignee | ||
Updated•20 years ago
|
Attachment #166741 -
Flags: review?(vladd)
Comment 13•20 years ago
|
||
Comment on attachment 166741 [details] [diff] [review] Trivial solution for the 2.18 branch and the trunk, v1.1 Nice to see identation for <noscript>, although [%IF Param("usebugaliases") %] and the corresponding [% END %] are still not idented (unlike the original): - [% IF Param("usebugaliases") %] - It is neither [% terms.abug %] number nor an alias to [% terms.abug %] - number. - [% END %] + [% IF Param("usebugaliases") %] nor an alias + to [% terms.abug %] number[% END %].
Attachment #166741 -
Flags: review?(vladd) → review+
Assignee | ||
Comment 14•20 years ago
|
||
(In reply to comment #13) > (From update of attachment 166741 [details] [diff] [review]) > Nice to see identation for <noscript>, although [%IF Param("usebugaliases") %] > and the corresponding [% END %] are still not idented (unlike the original) This is because I write [%IF Param("usebugaliases") %] [% END %] "inline", not as a block! :)
Comment 15•20 years ago
|
||
Checking in template/en/default/global/user-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v <-- user-error.html.tmpl new revision: 1.61.2.5; previous revision: 1.61.2.4 done Checking in template/en/default/global/user-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v <-- user-error.html.tmpl new revision: 1.74; previous revision: 1.73 done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 16•19 years ago
|
||
*** Bug 164522 has been marked as a duplicate of this bug. ***
Comment 17•19 years ago
|
||
*** Bug 149352 has been marked as a duplicate of this bug. ***
Updated•11 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•