Closed Bug 654125 Opened 13 years ago Closed 13 years ago

OS X: Firefox Find Bar should not transfer to global Find pasteboard by default

Categories

(Firefox :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: kwiniec, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17

Currently, OS X and other applications can see everything the user types into the Find bar because it gets into the OS X global Find pasteboard.  I believe this violates convention/expectation, and so should at least require the user's explicit permission.

Reproducible: Always

Steps to Reproduce:
1.  In TextWrangler, hit Command-F and search for a term.
2.  In Firefox, hit Command-F and search for a different term.
3.  In TextWrangler, hit Command-G to "Find Again".

Actual Results:  
TextWrangler magically searches for whatever you just typed into the Firefox Find bar.

Expected Results:  
TextWrangler should continue searching for the same term it searched for before, and should not be able to detect what you typed into Firefox.

BareBones provides "defaults write com.barebones.textwrangler FindDialog:UsesFindScrap -bool NO" to stop it from using the global Find pasteboard, but I think Firefox should not be putting user's Find data there in the first place, at least without the user's explicit permission.

My understanding is that the convention/expectation of Command-C, Command-X, and Command-V is global while that of Command-F and Command-G is local, and that the probability of someone wishing to find the exact same term on a Web page in a browser and on an unrelated document in an unrelated application is too low to warrant violating the convention.
Does that happen with other native Apple applications like Text Edit and Firefox for you? I can't reproduce your described issue with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0a2) Gecko/20110511 Firefox/5.0a2
Version: unspecified → 3.6 Branch
Good question!   The only Leopard app I've found so far exhibiting the same behavior as TextWrangler is Terminal.  Console, Finder, Preview, Safari, Spotlight, and Textedit all appear not to use the global Find pasteboard that way.  But I think even one app that can see what I type into Firefox Cmd-F is one too many.
I'm not able to reproduce that with Terminal and Firefox. Steven or Josh, could you help out?

Also is this still existent in Firefox 4.0.1?
Yes, 4.0.1 exhibits the same behavior.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
I can't reproduce this on OS X 10.6, either (using the STR from comment #0).

Maybe this problem has been "fixed" at the OS level.
I *can* reproduce it on OS X 10.5.8.

I'll look around to see if this is documented anywhere, and to find out whether Apple has specifically addressed this problem on OS X 10.6.

If so, there's probably not much we can or should do about it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This isn't a Firefox bug ... or at least not only a Firefox bug.

I can also reproduce it (on OS X 10.5.8) using TextWrangler and Safari.
(Following up comment #6)

> I'll look around to see if this is documented anywhere, and to find
> out whether Apple has specifically addressed this problem on OS X
> 10.6.

I can't find any documentation for this (I tried searching on "global
Find pasteboard" and looking at quite a few of the hits).  And I can't
find any evidence that Apple has addressed this problem ... at least
publicly.

I did find mention of the "global Find pasteboard" in Apple's release
notes for OS X 10.5 (in reference to new capabilities of the
"NSTextView Find Panel"):

http://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKitOlderNotes.html#TextView

But no other OS X version release notes appear to contain the phrase
"global Find pasteboard".
If this is OS X 10.5-specific, I'm inclined to say it's somewhere between "won't fix" and "can't fix".  But I'm cc-ing a security guru, to find out his take on the problem.

Dan, what do you think?
-> unspecified

Since it happens in both FF 3.6.X and FF 4.0.1.
Version: 3.6 Branch → unspecified
This is not something I get worked up about, and if Safari exhibits the same behavior and it's fixed in 10.6 I'm happy to blame Apple.
OK, thanks.  I'll mark this WONTFIX.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.