User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre Type something in the find bar, close the find bar, delete text in the find bar and the status overlay seems to jump to the right hand side of the window: http://img811.imageshack.us/img811/9153/28371793.jpg Reproducible: Always Steps to Reproduce: 1. Open find bar 2. Reload webpage 3. Interact with find bar Actual Results: Status overlay jumps to right hand side of window. Expected Results: Status overlay stay on left hand side of window.

I think that's on purpose, and it's actually reacting to the mouse movement I think. It's designed to try to stay out of the way of the mouse pointer, so if you point at something you can still see it.

possibly related to bug 631270

Marking invalid as this was deliberately changed in bug 631270. However, see bug 638793 - which covers making the "switch to right" logic more intelligent.

Reopening given the number of reports that I've duped against this. Whilst the reason for the change made sense (not obscuring the found text), doesn't this go against ux-consistency? Is there a better way of doing this? eg: making the page scroll further than the found text, so that the URL overlay doesn't cover it up?

Is there at least a workaround in about:config somewhere for this? It's a frustrating (mis)feature. It doesn't save space, it makes the UI inconsistent and I never know where to look for status now...

Ping. This is a really annoying UI blooper.

It seems to me that the overlay appears on the right just from the fact that the Find bar is open (changed summary to reflect that). As such, hovering over a link while the find bar is open will break muscle memory and cause confusion/frustration. This is especially important given that once the find bar is open, it never goes away automatically and is persistent across all tabs. As I recall, there is the ability to cross cursor paths with the overlay to get it to switch sides. However, that is next to impossible if a link is at the top of the page while the Find bar and status overlay are at the bottom. (For example, try hovering over the bug link at the top of this page while the Find bar is open.) I don't see any solution to this that doesn't involve improved logic about where a Find result is, as proposed in bug 638793, so it's not clear to me how these two bugs are distinct. (This one explains the problem; that one proposes a solution.) I'll leave it to somebody else to mark this as a dupe; in the mean time, that bug is at least a blocker on this bug.

It just blew my mind when I saw that (using FF Aurora 7.0a2 - and then updated to 11.0a2) FF is smart enough to properly not-obscure text results on the LEFT HAND SIDE with the hover url even with the find bar open - but I realized later its checking the mouse position. STR: 1. find a link that will be in the bottom right of the screen. I used http://www.mozilla.org/en-US/firefox/channel/ with the texts and fonts and window size such that one of the blog titles (which are currently lower-left in the page) was large enough to be multi-line. E.g. "Firefox Beta with New Developer Tools and Enhanced Sync Is Ready for Testing" 2. hover-the link without find being open VP: the link-hover shows on the LHS 3. with the find bar open hover the link such that the mouse _does_ overlap where the hover would be VP. the link-hover shows on the LHS!!! 4. with the find bar open hover the link such that the mouse does NOT overlap where the hover would be VP. the link-hover shows on the &%*$ing RHS!!! The expected behaviour should be on the LHS every time. In my mind the correct behaviour is to scroll the document so the hover does not obscure it. If the hover obscures the found text and it is the BOTTOM of the page and there's no where to scroll THEN maybe bump the hover to the RHS. Another option - I have a bottom bar that apparently right-clicks to show toolbar options - so it is a toolbar. I didn't add it, it's empty, I just removed it, but it could have been used to show the hovered url. This just drives me NUTS. It makes it SO hard to find links on some webpages.

This isn't needed anymore now that bug 171237 is fixed.

(In reply to Dão Gottwald [:dao] from comment #21) > Created attachment 597386 [details] [diff] [review] > patch > > This isn't needed anymore now that bug 171237 is fixed. Will the fix in bug 171237 also fix the issue of the Find module jumping from the left to right hand side of the screen when the mouse passes over it? If not, I think this issue stands.

(In reply to Adam Cohn from comment #22) > Will the fix in bug 171237 also fix the issue of the Find module jumping > from the left to right hand side of the screen when the mouse passes over > it? If not, I think this issue stands. I don't understand what issue you're referring to.

Sorry, I meant the status overlay. The status overlay shouldn't flip to the right hand side of the screen when the Find module is open. See this screenshot: http://i.imgur.com/U7SYI.jpg

(In reply to Adam Cohn from comment #25) > Sorry, I meant the status overlay. The status overlay shouldn't flip to the > right hand side of the screen when the Find module is open. See this > screenshot: http://i.imgur.com/U7SYI.jpg That patch I attached here removes this behavior.

Comment on attachment 597386 [details] [diff] [review] patch >--- a/browser/base/content/tabbrowser.xml >+++ b/browser/base/content/tabbrowser.xml > <method name="_calcMouseTargetRect"> > <body><![CDATA[ >- let alignRight = (window.gFindBarInitialized && !window.gFindBar.hidden); >+ let alignRight = false; > > if (getComputedStyle(document.documentElement).direction == "rtl") > alighRight = !alignRight; Noticed in passing that this sets alig*h*Right. Dão, could you file a bug, perhaps?

(In reply to Ms2ger from comment #28) > Comment on attachment 597386 [details] [diff] [review] > patch > > >--- a/browser/base/content/tabbrowser.xml > >+++ b/browser/base/content/tabbrowser.xml > > <method name="_calcMouseTargetRect"> > > <body><![CDATA[ > >- let alignRight = (window.gFindBarInitialized && !window.gFindBar.hidden); > >+ let alignRight = false; > > > > if (getComputedStyle(document.documentElement).direction == "rtl") > > alighRight = !alignRight; > > Noticed in passing that this sets alig*h*Right. Dão, could you file a bug, > perhaps? bug 727793

Comment on attachment 597386 [details] [diff] [review] patch Bug 171237 was fixed for Firefox 12, so it makes sense to take this for Firefox 12 as well. It's just code removal, so low risk.

Comment on attachment 597386 [details] [diff] [review] patch [Triage Comment] Approved for Aurora 12 in support of bug 171237, which also landed in Firefox 12.

Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 Verified on Windows 7, Mac OS 10.6, Ubuntu 11.10 with Firefox 12 beta 4 with the following steps: 1. Visit bugzilla.mozilla.org 2. Click Find. 3. Reload. 4. Hover a link. 5. Type something in the address bar. 6. Hover a link. The status overlay is now always displayed in the left hand side.