Open Bug 452911 Opened 16 years ago Updated 2 years ago

Search icon on "Get add-ons" window shows hand-cursor instead of the default one if I hover it

Categories

(Toolkit :: Themes, defect)

defect

Tracking

()

People

(Reporter: Gabri, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Build Identifier: If I hover or click the searchbox icon on 'Get add-ons" window it shows hand-cursor instead of the default one. Reproducible: Always
Depends on: 388811
Component: Theme → Add-ons Manager
Product: Firefox → Toolkit
QA Contact: theme → extension.manager
Version: unspecified → Trunk
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
No longer depends on: 388811
Resolution: --- → DUPLICATE
hmm, it's still using cursor: pointer somehow with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080830031750 Minefield/3.1b1pre ID:20080830031750
Attached patch patch? (obsolete) (deleted) — Splinter Review
this must have regressed somewhat as it works in Fx 3.0.1
Attachment #336189 - Flags: review?(dtownsend)
Comment on attachment 336189 [details] [diff] [review] patch? This patch is invalid
Attachment #336189 - Attachment is obsolete: true
Attachment #336189 - Flags: review?(dtownsend)
Attached patch patch, 2nd try? (deleted) — Splinter Review
patch encoding hassle ...
Attachment #336192 - Flags: review?(dtownsend)
Status: RESOLVED → UNCONFIRMED
Component: Add-ons Manager → XUL Widgets
OS: Windows XP → All
QA Contact: extension.manager → xul.widgets
Resolution: DUPLICATE → ---
Attachment #336192 - Flags: review?(dtownsend)
Blocks: 388811
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Attachment #336192 - Flags: review?(enndeakin)
Assignee: nobody → xtc4uall
Status: NEW → ASSIGNED
Attachment #336192 - Flags: review?(enndeakin) → review+
Comment on attachment 336192 [details] [diff] [review] patch, 2nd try? Seems OK.
So how do you expect the user to realize that the icon is interactive?
(In reply to comment #7) > So how do you expect the user to realize that the icon is interactive? Same also applies to the web search field inside the navigation toolbar. It even doesn't use a pointer. At least all the fields should be consistent across the UI. AFAIR these are the ones who trigger an external search, correct?
type="search" textboxes in searchbutton mode look exactly like those in search-on-input mode. (The search glass gets a very subtle hover effect on Windows but not on Linux.) It's not obvious at all that searching in the add-ons manager is remote; theoretically, the list could be fetched beforehand, or we could search on input with a bigger timeout to avoid bad requests. In case of the Search bar it's clear that the search can't happen on input.
well, i just want to have the behavior reverted/fixed as bug 427689 did before landing of bug 388811.
Bug 427689 says "this is not native behavior on any platform", but it's not clear to me what comparable native widget that statement refers to.
(In reply to comment #8) > (In reply to comment #7) > > So how do you expect the user to realize that the icon is interactive? > > Same also applies to the web search field inside the navigation toolbar. It > even doesn't use a pointer. Btw, this is wrong for Gnomestripe.
Component: XUL Widgets → Themes
QA Contact: xul.widgets → themes
Assignee: xtc4uall → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: