bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Searchbar's "Paste & Search" erases non-selected, inconsistent with "Paste" .

VERIFIED WONTFIX

Status

()

Firefox
General
VERIFIED WONTFIX
8 years ago
7 years ago

People

(Reporter: Rob, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101203 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101203 Firefox/4.0b8pre

The Searchbar's "Paste & Search" feature will erase the non-selected text in the Searchbar but it you used "Paste" (or CTRL-V) the non-selected text would not be erased (which is the correct operation).


Reproducible: Always

Steps to Reproduce:
1. The "User Situation" one would be in where this might occur is that you had your Searchbar set to use Google, you typed something in and searched; unhappy with the result yet unwilling to loose your findings you open a NEW Tab.
2. In the NEW Tab (click the "Tab" at the bottom and the "Page" itself if you MUST) mouse up to the Searchbar again and click there.
3. The text in the Searchbar is high-lighted; click again (at the end of the text) or hit right-arrow to UN-select the text, then hit the Spacebar.
4. Select a small portion of the Searchbar's text (or ALT-TAB to a text document and copy (CTRL-C) a SHORT text string into the Clipboard).
5. This is where the BUG is:

  5a. Use CTRL-V to "Paste" the text from the Clipboard into the Searchbar. Since the text in the Searchbar is un-selected you can add additional word from different document in PREPARATION of narrowing your search. When you have enough words accumulation simply click the magnifier and "Google" (or other search tool) will load into the previously blank Page.

  5b. You don't need yet another Tab but you could open one more first if you wish. Move the mouse over the Searchbar and use the left mouse button to UN-select the text (click at the END of it). Now use the right mouse button to choose "Paste & Search". Notice the BUG.

Actual Results:  
The "Paste & Search" acts like it is:

1. CTRL-A .
2. CTRL-V .
3. CTRL-M .


Expected Results:  
The "Paste & Search" should ONLY be:

1. CTRL-V .
2. CTRL-M .


I search before I posted and found this un-related Bug 597237 .

Updated

8 years ago
Version: unspecified → Trunk

Comment 1

7 years ago
Confirming on win 7 pro with firefox 4

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

7 years ago
Blocks: 492544

Comment 2

7 years ago
This is the opposite of bug 616678.
Blocks: 599793
No longer blocks: 492544
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 3

7 years ago
(In reply to comment #2)
> This is the opposite of bug 616678.

Please comment on why this was closed or CORRECTLY refer to the relevant Bug Report number - it can not be "the opposite of bug 616678" (itself).

Please re-open if closed in error since this Bug still occurs AND has been confirmed.

Thanks,
Rob

Comment 4

7 years ago
I can confirm. This happens in a lot of cases. The symptoms look like lazy coding. 

PLEASE REOPEN!
This occurs on ubuntu 11.04 and knoppix if it matters.
A bug can't be an opposite unless it proposes a fix that would change the expected behavior, such as changing what website the search goes to.

Comment 5

7 years ago
Please read comment 2 as "This is the opposite of bug 599793"


Hi :Boriss,

Please reconsider reopening this bug.

Rational:-
In my case since using Turbo pascal IDE (20+ years),
and for everybody, definitely since they started using MS-Windows, 
paste function always replaced the current selection 
(ie, not entire line or field).
But bug 599793 totally changed this grand old convention, 
and hence totally confusing average firefox user.

Additionally bug 599793 was originally field for just URL bar, 
and not the search field 

Only time replacing the entire URL bar is useful when 
the "clipboard" content is a URL.
So I would like to suggest limiting bug 599793 to just that.
Along with an additional option to completely 
disable bug 599793 using about:config.
This is because when ever user bring focus to url bar by clicking it, 
its text content automatically get is selected.
And then a "Paste and Go" on it work as expected by bug 599793 even 
without that bug being fixed.
(Reporter)

Comment 6

7 years ago
Thank you Biju (on Frank's behalf) for mentioning Bug 599793. I have read that Bug.


In Bug 599793 Justin Lebar (the Origonal Reporter) says that HIS Report is for "Paste & Go". He can report what he wishes that is his choice. Justin does NOT report for "Paste & Search" and that is HIS choice also. 

_IF_ Justin had chosen to report TWO different Bugs in ONE Report then someone (should have been Frank or another Modererator) would have strongly discouraged (Frank!) him from doing so. It is not neccesarily a "Prohitited Action" but it is one that is almost always "discouraged" (here at Mozilla's Bugzilla).

In Bug 599793 Comment 2 it is Frank who decides to make Justin's Bug Report apply to something that was not a Problem and was working correctly - Frank created a "Bug" by suggesting this effect for the purpose of "UI consistency".

Int the next comment "Alexander Limi (:limi) — Firefox UX Team 2010" agreed with Frank. In the next comment Justin agrees to it also.



I do not agree that Bug 599793 needed to be reported and fixed, one simply needs to make certain that all the text is selected BEFORE they Paste. It MAY be slightly easier to not have to select it but then that makes it harder to add to the text (which in THAT particular Case is likely not done very often).


In THIS CASE (Bug 616678) it (additive Pasting) is quite likely to be done AND we (now) have a few people complaining (here) about the repair of "a Bug that never existed" wrecking OUR usage of the UI. 

Their fix of their lazyness (not to select before Pasting) has inhibited our ability to use the Browser "normally" (we will select if WE desire, don't IMPOSE it on us as that goes against a "UI").


Such sentiments are also echoed in Bug 599793:

In the next Comment gingerbread.guy@live.com says:
'The "Paste and Go 2" extension (and presumably, its predecessor and successor as well) has a preference which offers a choice between replacing the whole address or replacing the selection. I have it set to the latter'.

Bug 599793 ends at Comment 17 with Mike Beltzner [:beltzner] supplying a Patch.



Please do not mark this BR as "RESOLVED WONTFIX" when in fact is is NOT "resolved" is was CAUSED by Bug 599793's (un-needed) so-called "fix" stomping on the User's rights to the UI (as evidenced by all the complaints HERE, yet only ONE there).


You "fix" in Bug 599793 IS EQUALLY AS BAD as making "Paste & Go" only paste and goto "http://www.google.com/" and not allowing the User to choose what they desire to Paste. Why not wreck the UI that way and "fix" Bug 599793 by forcing what to paste instead of being the cause of Bug 616678 - you see my point now.

Thanks,
Rob


REOPENED.

Reason: Bug 599793 exceeded it's boundaries and breached the "Principles of UI".

It was CLAIMED, that it was correct thinking, that there were TWO Bugs (on the basis of "consistency") when in fact such action (fixing a "non-Bug" and catering to lazyness) created THIS "Bug". That went against the "Principles of UI" (by making the UI less usable and dictating an unwanted feature ELSEWHERE, not WHERE the "Bug" was reported, in the UI).


The usefullness of "fixing the other Bug" is debatable (there, not here) but the usefullness of this feature (described here) is obvious and needed, thus it ought not to be removed.

Moral: Don't "fix" what is not broke to break something you don't want to fix.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 7

7 years ago
Rob, you are misunderstanding the process of bug 599793 almost entirely. Of course, Justin Lebar filed the bug 599793 for Paste & Go, and my extension of the bug to apply it to Paste & Search was both without his objection and with the support of the UX team.

More importantly, please do not reopen bugs for which there is already a consensus that the existing behavior is desired. We will not take a patch for this.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → WONTFIX

Updated

7 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 8

7 years ago
I tried http://menueditor.mozdev.org/ but unfortunately it won't go into the URL and Search Bars (at least in Aurora FF6).


There seems a few promising options:

Tweak chrome for a cleaner Firefox:
http://eriwen.com/firefox/howto-tweak-chrome-for-a-cleaner-firefox/

Modify the right-click to completely remove the option:
http://www-archive.mozilla.org/unix/customizing.html#usercss

_and_

Modify the right-click to run a Script that does the correct thing:
http://piro.sakura.ne.jp/xul/doc/ctxextensions/help.xml.en


I'll do some work using the above methods and see if I can derive the shortest possible code to either remove the 'feature' or restore the previous correct operation (according to what the Command "says" that it does). It needs to be a simple fix for the end user. In the meantime 

I will refer any requests in my OTHER BRs to Frank; since he has decided we are switching Jobs.



For the 'new mode of operation' to be correct it would mean that when we pasted a word into a Document or pasted a File to a Directory it would be at the expense of all the rest of our work. 

Can you imagine pasting a File and deleting your Harddrive (expect for that one file), a useful feature in very limited circumstances.


Correct English would dictate that the modified Command should NOW be be called "Goto Pasted" and "Search Pasted" and NOT "Paste & Go" and "Paste & Search" - because that is NOT what it does (as clearly explained in the OP). 

Lazy coding has already been suggested by another poster in this Thread. I suggest People not use "Google Translate" to read the BRs, it is against Policy. 

Much like "Air Traffic Control" is done in English so are "Computer Programming Languages" (except APL http://en.wikipedia.org/wiki/APL_(programming_language) and some other rarities) and thus, so are Computer Programs (IE: Firefox).


I'll not play games with the WONTFIX Button, I've owned a Computer for likely longer than Frank has been alive and I am not a Child (or illiterate). I know how the Computer's UI works.

I'll post a Fix when I derive one; if someone is expert with Chrome or XUL Extensions your welcome to post here. I'll request a "Patch Reversal" in the other Thread sometime in future, when I have some spare time.
(Reporter)

Comment 9

7 years ago
After some work related delays I have had time to come back to this and post the fix.

Disclaimers: I'm using Firefox version 7.0a1. My setup may differ from yours, your mileage many vary, objects in the mirror ..., etc.


1. You may need to get setup to use userChrome.css there is some info here: http://www.mozilla.org/unix/customizing.html

"The userChrome.css does not exist by default. If you want them, you create them in the chrome subdirectory underneath the user's profile directory...".


2. That directory (depending on your setup) is:
C:\Documents and Settings\HP_Administrator\Application Data\Mozilla\Firefox\Profiles\kldibvsr.Namoroka\chrome\


3. If you do not have this file already then create a "userChrome.css" file. 

You can edit this easily if you install the Plug-in "MR Tech's" "Local Install" http://www.mrtech.com/extensions/local_install/ and use the "Edit My Config" feature but it is not necessary.


4. The  "userChrome.css" file is:

/*
 * Edit this file and copy it as userChrome.css into your
 * profile-directory/chrome/
 */

/*
 * This file can be used to customize the look of Mozilla's user interface
 * You should consider using !important on rules which you want to
 * override default settings.
 */

/*
 * Do not remove the @namespace line -- it's required for correct functioning
 */
@import url(chrome://global/skin/j-gray.css);
@import url(chrome://browser/skin/j-nav-gold.css);

/* CuteMenus - Crystal SVG --- Hide Icons for Disabled Menu & Menu Items */
@import url("chrome://cutemenus/content/cutemenus_hide_disabled.css");

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /* set default namespace to XUL */



menuitem[anonid="paste-and-go"],
#searchbar menuitem[anonid="paste-and-search"]
{ visibility:collapse !important; }


5. If you already have a userChrome.css file then just add the last Section only.


6. Exit and restart Firefox (I'm using version 7.0a1).


7. Now the "(delete contents, then) Paste and Search" annoyance will be missing. You still have "Paste" and can use your Thumb on the Numeric Pad's [Enter] Key to initiate the search (assuming the searchBar has focus).


This fix is completely compliant with the UI and for a bonus we've knocked off "Paste and Go", but you could put it in without ruining it for the rest of us.

Next time ASK if your change in ANOTHER Bug would stomp on other People, it is courteous. 

It is not appreciated to mark other Bugs as dupes or wontfix and close Bugs without any consultation. I've had to wait weeks for a reply when I asked the OP if we could close their Bug.
You need to log in before you can comment on or make changes to this bug.