Closed Bug 631250 Opened 9 years ago Closed 8 years ago

Status overlay switches to right side of window when find bar is open

Categories

(Firefox :: General, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 13
Tracking Status
firefox12 --- verified

People

(Reporter: iaTa, Assigned: dao)

References

(Blocks 1 open bug)

Details

(Whiteboard: [qa+])

Attachments

(1 file)

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.
Version: unspecified → Trunk
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.
Blocks: 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.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Duplicate of this bug: 644251
Duplicate of this bug: 644650
Duplicate of this bug: 645030
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?
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Depends on: 640132
Duplicate of this bug: 646426
Duplicate of this bug: 647461
Blocks: 541656
Duplicate of this bug: 649816
Duplicate of this bug: 650738
Duplicate of this bug: 651893
Duplicate of this bug: 640005
Duplicate of this bug: 657593
Duplicate of this bug: 663912
Duplicate of this bug: 666419
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.
Depends on: 638793
Summary: Status overlay switches to right side of window when find bar is interacted with → Status overlay switches to right side of window when find bar is open
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.
Blocks: 638793
Depends on: 171237
No longer depends on: 638793
OS: Windows 7 → All
Hardware: x86 → All
Blocks: 641240
Attached patch patchSplinter Review
This isn't needed anymore now that bug 171237 is fixed.
Assignee: nobody → dao
Status: REOPENED → ASSIGNED
Attachment #597386 - Flags: review?(gavin.sharp)
Attachment #597386 - Flags: review?(gavin.sharp) → review+
(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.
https://hg.mozilla.org/mozilla-central/rev/192068c13792
Status: ASSIGNED → RESOLVED
Closed: 9 years ago8 years ago
Resolution: --- → FIXED
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.
Attachment #597386 - Flags: approval-mozilla-aurora?
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.
Attachment #597386 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [qa+]
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.
You need to log in before you can comment on or make changes to this bug.