Closed
Bug 133350
Opened 23 years ago
Closed 23 years ago
Search item should not be in context menu when there's no selection
Categories
(SeaMonkey :: UI Design, defect)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: bugzilla, Assigned: samir_bugzilla)
References
Details
spun off from bug 132626 --the Search item should not be in the context menu if
there is no selection.
o'course, this bug might become invalid (or, heh, just *fixed*) once the
reorganized context menus (bug 75338) are implemented.
however, the fact that this non-context relevant item is present (it's just
greyed out when there's no selection) is a regression. i don't have many
intermediate builds on my current machine, but this was not an issue with 3/13
bits --it is in 3/22 bits.
Reporter | ||
Updated•23 years ago
|
Depends on: 75338
Keywords: nsbeta1,
regression
Assignee | ||
Comment 1•23 years ago
|
||
This is not a regression. This was an enhancement that was part of polishing
search. CC'ing folks who lobbied for this.
Given the new spec this should probably go to whoever is implementing the new
context menus. I'm happy to fix it though. Blake, you want this?
Keywords: regression
Comment 2•23 years ago
|
||
this item should be shown at all unless there's a selection.
Comment 3•23 years ago
|
||
sorry, this item should >not< be shown at all unless there's a selection.
Comment 4•23 years ago
|
||
So who are all these people who randomly select text on web pages to see if new
right-click menu items show up? How will anyone ever discover the search
functionality? I only discovered it because I filed an enhancement request to
implement such a feature and it got immediately closed with "we've had that for
months already".
"Context" should mean where you are on a page (plain text, frame, text area),
not whether stuff is selected. Selected text makes sense as a "state" which
might affect the items present, but it's damn confusing when it affects which
items show at all.
Comment 5•23 years ago
|
||
Context would include things such as selection. I sympathize with Dan's point,
but even if it is there with no selection, I doubt most people would get that
the disabled'Search for <select term>" becomes enabled and meaningful when there
is a selection.
Comment 6•23 years ago
|
||
While I generally agree with the premise that items in the context menus should
only appear when they are available, I think our view on this is too strict
here. Dan is right, no one will ever find this very cool feature otherwise.
Putting it there, disabled, with the text "Search Netscape Search for <Selected
Text>" would go a long, long way to making the feature discoverable and used.
As it tends to be a more savvy user that is using context menus anyway, I think
many of them will be able to figure out how this feature works if we do this.
Frankly the bottom line is that it will help a lot more than it would hurt to
bend the rules here.
I've had more than one person ask me about this feature already, and as Dan
found out, I've told them it's already in. You know what they say? They say
they never would have found it and why isn't it there when text isn't selected.
You know what we will likely never hear from our users if we do this? We will
never hear "but it shouldn't appear in the context menu when I don't have
something selected". We need to have this in the menus.
Reporter | ||
Updated•23 years ago
|
OS: Linux → All
QA Contact: paw → sairuh
Hardware: PC → All
Comment 7•23 years ago
|
||
just for reference the bug that called for this addition in the first place is
bug 114972.
for my .02 this bug should be 'wontfixed'. While it is true that not a ton of
people will put together the greyed-out text with the new feature and what
actions they can take, that number is orders of magnitude greater than the
number of people who will figure out this feature without the text(presumably
through clairvoyance).
Let's leave this contextitem in until someone presents a better sol'n for
discoverability and we can implement that. Let's temper the knee-jerk reaction
to pull this simply b/c it's non-standard.
Bear in mind as well here that the audience is people who use context menus.
That's a *slightly* more enlightened subset that Joe User and they may actually
have a chance at 'getting it'.
Comment 8•23 years ago
|
||
I find the addition of this item in the context menu annoying and distracting -
but suppose that it's something I can live with. There do seem to be more
arguments for keeping it there, disabled, than not.
However. Is there *ANY* way that I can turn off the icon, leaving just the
text? The fact that this is the only context menu item that has an icon makes
it far too obvious for my liking. I've had Smart Browsing / Internet Keywords
(and Show Web Site Icons) disabled for months now and had hoped I'd seen the
last of such graphics...
Assignee | ||
Comment 9•23 years ago
|
||
Nav triage team: nsbeta1-
Comment 10•23 years ago
|
||
WFM in a 04/03 build (probably from bug 75338).
Re discoverability: users will discover the search-from-context-menu feature
when they try to copy text from a web page to paste into a search engine.
(Especially if we remove the useless "cut" and "paste" options, making "copy"
first and "search" second or third.)
Reporter | ||
Comment 11•23 years ago
|
||
thanks for checking, jesse --i'll also check commercial verif bits once those
are available.
Reporter | ||
Comment 12•23 years ago
|
||
this also wfm using 2002.04.03.14 comm verif bits on linux rh7.2.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•