631270 - Status panel gets in way / obscures a Find result at the bottom of the page

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Alice0775 White]

Attachment: sample html

After landing Bug 541656,

Find range is covered by Status Tooltip

Reproducible: Always

Steps to Reproduce:
1. Start Minefield with new profile
2. Open attached html
3. Press Ctrl + F
4. Type "Firefox" in findbar
5. Click contents area
6. Press F3 and repeat

Actual Results:  
 Find range is covered by Status Tooltip

Expected Results:  
 Shuld not. 
 Anchor url and the find range should be visible both.

Comment 1

[Alice0775 White]

Attachment: screenshot

Comment 2

[Alice0775 White]

Attachment: sample html

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking, would take a patch.

Comment 4

[Alice0775 White]

Attachment: sample html

[str]
1. keypress / (Start quick find)
2. keypress minefield

[Actual]
You cannot see find region, because the Status overlay covers it.

[Expected]
The Status overlay should go away.

Comment 5

[Dão Gottwald [:dao]]

How about just displaying the status panel on the opposite side when the find bar is open? That might be a cheap stop-gap solution, avoiding the issue most of the time.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

That would be a fine quick fix. If we don't fix this somehow before Firefox 4 I'm going to go crazy.

Comment 8

[Dão Gottwald [:dao]]

Attachment: patch

Comment 9

[Alice0775 White]

(In reply to comment #5)
> How about just displaying the status panel on the opposite side when the find
> bar is open? That might be a cheap stop-gap solution, avoiding the issue most
> of the time.
It is not solved in the following sites
http://hibari.2ch.net/software/

Comment 10

[Dão Gottwald [:dao]]

Yes, the current patch is supposed to merely mitigate the problem. Alternatively, we could suppress the status panel altogether when the find bar is open.

Comment 11

[Alice0775 White]

If we adopt comment 5, we should consider LTR contents in RTL browser.
and vice versa.

Comment 12

[Dão Gottwald [:dao]]

I actually considered that. Again, that approach mitigates the problem, it doesn't really solve it.

Comment 13

[Dão Gottwald [:dao]]

Comment on attachment 510588 [details] [diff] [review]
patch

will try something slightly different

Comment 15

[Dão Gottwald [:dao]]

Attachment: patch v2

Comment 16

[Dão Gottwald [:dao]]

Attachment: patch v3

more fine-tuning

Comment 19

[Dão Gottwald [:dao]]

Attachment: patch v3

updated to tip

Comment 20

[Jesse Ruderman]

Renominating.  This bug pretty much breaks the Find Again feature: if the found text is a link on the left side of the page, you can't see it.

My steps:
1. Cmd+F Orange
2. Load http://en.wikipedia.org/wiki/Wikipedia:Lamest_edit_wars
3. Cmd+G

Comment 21

[Jesse Ruderman]

I don't think this patch helps much. The find bar is not necessarily open when using Find Again, and the found link text is not necessarily on the left (start) side of the page.

I'd rather see a patch that also fixes bug 631292, by taking the position of the selection into account (just like we take the position of the mouse cursor into account for hovered links).

Comment 22

[Mike Beltzner [:beltzner, not reading bugmail]]

Best I'll give this is soft blocking status so it has pre-approval to land, but that's about it. As soon as you move the mouse around a bit, it stops obscuring the result.

Yes, it sucks. Welcome to the risk inherent in late-feature-adds.

Comment 24

[timeless]

when i use find-again, the find bar is indeed often closed, so if this doesn't handle that case, then it isn't very helpful :(

it seems like you'd want to change what 'view' is for scrollIntoView..

Comment 25

[Mike Beltzner [:beltzner, not reading bugmail]]

If this passes reviews, it has implicit a=beltzner

Comment 28

[Steven Robertson]

The "Quick-Find (links only)" dialog box suffers from the same problem, and the attached patch doesn't seem to fix this (although it does indeed fix find-again).

I use this literally hundreds of times a day to browse documentation, so it's a significant annoyance.

Thanks for your help.

Comment 30

[Mike Beltzner [:beltzner, not reading bugmail]]

Gavin and I just talked about this IRL after he showed me his proposed fix, which was to move the Status Bar to the right hand side of the screen and overlay the Find Bar so as not to obscure results in content:

http://grab.by/grabs/32c5098543f29068d926ec4033f6d742.png

I remarked that this looked like a rendering bug, and he made me realize that there could be find-match content on the right-hand side of the screen.

Ick.

So then I went back to the foundations for a moment: why are we showing link-hover preview when we find text? I don't think it's all that valuable, and once the text has been found the user can mouse over it to see the link preview. Further, Quick Find does not show link preview (although Quick Find - links only does). It seems to me that the easiest solution is:

 - make the Find Bar behaviour match Quick Find
 - make Quick Find (links only) match Quick Find
 - when the Find Bar or Quick Find Bar is open, move the Status Bar to the right

This will still cause problems in the case where someone is using Find or Quick Find while the page is loading and the match is in the bottom row on the right, but I think that's acceptable as most users are on wider and wider screen monitors with mostly whitespace on the right hand side. Also, it's only temporary until the site stops loading.

dbolter: does this have an a11y impact I'm not seeing around not showing the Status Bar for link preview when using Quick Find (links only) mode.

Comment 31

[Mike Beltzner [:beltzner, not reading bugmail]]

Hrm. Apparently I was seeing some other bug, and Quick Find does show link hover previews by default.

No matter - my suggestion is the same, really, just:

 - do not show link hover preview for Find Matches until the user mouses over them
 - when the Find Bar or Quick Find Bar is open, move the Status Bar to the right

Comment 32

[Dão Gottwald [:dao]]

> http://grab.by/grabs/32c5098543f29068d926ec4033f6d742.png

> he made me realize that
> there could be find-match content on the right-hand side of the screen.

I'm not sure what find-match content means (on the find bar? in content?), but the overlay dodges if you move the mouse over it.

Comment 33

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #30)
> dbolter: does this have an a11y impact I'm not seeing around not showing the
> Status Bar for link preview when using Quick Find (links only) mode.

This question is now moot right?

Aside: obviously, obscuring content is an accessibility-as-usability issue but probably not as big an issue for screen reader users :)

By the way Marco, do screen readers pick up the url link preview? I think we'll need a separate bug for that. Might want to make it an aria-live region or something.

Comment 34

[Dão Gottwald [:dao]]

> By the way Marco, do screen readers pick up the url link preview?

role="status" should cover that.

Comment 35

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #34)
> > By the way Marco, do screen readers pick up the url link preview?
> 
> role="status" should cover that.

Excellent. Thanks Dão. Is this the same component as the connecting/waiting/loading status overlay?

Comment 36

[Dão Gottwald [:dao]]

(In reply to comment #35)
> Is this the same component as the connecting/waiting/loading status overlay?

yep

Comment 37

[Stanley Chan]

Google Chrome /tries/ to avoid this bug by centering the browser around the quick find highlighted text (vertically). I am not sure what it does if the highlighted text is at the bottom-most parts of the screen.

Comment 38

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #32)
> I'm not sure what find-match content means (on the find bar? in content?)

In content - beltzner didn't like the status widget being "on top" of the findbar chrome, but I pointed out that if we don't do that in addition to the side-change, there are still situations where the status bar can obscure highlighted find results (i.e. when those results are on the right of the page).

Comment 39

[Olli Pettay [:smaug][[e-mail]]]

I was trying locally a patch where we scroll the page more when a new
result is found (something close to what Chrome does - the focused search result
is scrolled to the middle of the page) but that affected usability pretty badly.
(and doesn't solve the problem in all the cases)
In some cases it was hard to find where the result is.

Comment 40

[Olli Pettay [:smaug][[e-mail]]]

Attachment: scroll more when a new result is found

Comment 41

[Scott Baker]

Is it possible to detect if the searched content is on the left/right side and display the url tooltip hover on the opposite side?

Comment 43

[Scott Baker]

In response to my own comment (#41) I realized that if you mouse hover over a link that's on the left side the popup shows on the right. And also vice versa. Seems like a pretty elegant solution, we just need to do the same thing for the find result.

Comment 44

[Adam Nielsen]

I just encountered this with Firefox 4 beta 12.  When you search for text which happens to match a link, the status bar appears over the top of the result with the link destination (i.e. no hovering required.)

For me the perfect solution would be to just scroll up slightly further, i.e. the code that figures out whether the result is visible needs to be told the page is about 16 pixels shorter than it actually is.

Comment 45

[Mardeg]

(In reply to comment #44)
> For me the perfect solution would be to just scroll up slightly further, i.e.
> the code that figures out whether the result is visible needs to be told the
> page is about 16 pixels shorter than it actually is.

That's bug 171237
Doncha wish we'd thought ahead and fixed it by now? :(

Comment 49

[Dão Gottwald [:dao]]

Attachment: hide the panel when the find bar is open

Comment 50

[Alice0775 White]

(In reply to comment #49)
> Created attachment 516214 [details] [diff] [review]
> hide the panel when the find bar is open

While the FindBar opens, where is the focused link URL shown?  Where is the mouse hover link URL shown?

Comment 51

[Dão Gottwald [:dao]]

(In reply to comment #50)
> While the FindBar opens, where is the focused link URL shown?  Where is the
> mouse hover link URL shown?

Nowhere.

Comment 52

[Alice0775 White]

(In reply to comment #51)
> Nowhere.
I think that it is not good at all.

Comment 53

[:Gavin Sharp [email: [e-mail]]]

I think we really need to address this, but I'm not sure either of the current approaches are ideal (patch v3 has the odd "overchrome" behavior, and hiding unconditionally when the find bar is open is a pretty serious loss of functionality which could be confusing).

How about going with "patch v3"'s approach, but not doing the "overchrome" stuff - i.e. just setting mirror="true" when the findbar is open?

Comment 54

[Dão Gottwald [:dao]]

(In reply to comment #53)
> How about going with "patch v3"'s approach, but not doing the "overchrome"
> stuff - i.e. just setting mirror="true" when the findbar is open?

This would be the first patch, attachment 510588 [details] [diff] [review], I think.

Comment 55

[YUKI "Piro" Hiroshi]

The found term can be got as a nsIDOMRange, and now we can get a client rectangle for the range. So, I think that we should set/unset mirror="true" only when the status panel's client rectangle covers the found range's rectangle.

Comment 56

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 510588 [details] [diff] [review]
patch

a=beltzner, with the understanding that Gavin will be watching like a HAWK for fallout, but it's OMGSAFE and fixes a common annoyance with the b11 statusbar change

Comment 57

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/000fe7de6636

Comment 59

[Olli Pettay [:smaug][[e-mail]]]

Please file a followup bug to fix this properly.

Comment 63

[jiri slaby]

(In reply to comment #59)
> Please file a followup bug to fix this properly.

Did anyone create the followup? What's the number then? The fix from comment #57 doesn't help much... Actually it doesn't help at all in most cases.

Comment 65

[George Carstoiu]

Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0

Verified issue and it's no longer present.

Comment 67

[j.j.]

(In reply to comment #63)
> (In reply to comment #59)
> > Please file a followup bug to fix this properly.
> Did anyone create the followup?

Bug 640132

Comment 69

[Daniel Holbert [:dholbert]]

Note that it's possible to continue performing "Find next" actions (F3/Ctrl-G) after the find bar is closed.  In that use-case, this is still broken.  I filed bug 664628 on that.