Closed Bug 631270 Opened 9 years ago Closed 9 years ago

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

Categories

(Firefox :: General, defect)

x86
All
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 4.0
Tracking Status
blocking2.0 --- final+

People

(Reporter: alice0775, Assigned: dao)

References

(Depends on 1 open bug)

Details

(Keywords: regression, testcase, Whiteboard: [softblocker])

Attachments

(7 files, 3 obsolete files)

Attached file sample html (obsolete) —
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.
Attached image screenshot
blocking2.0: --- → ?
OS: Windows 7 → All
Attached file sample html
Attachment #509465 - Attachment is obsolete: true
Not blocking, would take a patch.
blocking2.0: ? → -
Summary: Find range is covered by Status Tooltip → Status tooltip gets in way / obscures a Find result at the bottom of the page
Attached file 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.
Blocks: 630902
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.
Duplicate of this bug: 630902
No longer blocks: 630902
That would be a fine quick fix. If we don't fix this somehow before Firefox 4 I'm going to go crazy.
Attached patch patchSplinter Review
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #510588 - Flags: review?(gavin.sharp)
(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/
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.
If we adopt comment 5, we should consider LTR contents in RTL browser.
and vice versa.
I actually considered that. Again, that approach mitigates the problem, it doesn't really solve it.
Comment on attachment 510588 [details] [diff] [review]
patch

will try something slightly different
Attachment #510588 - Flags: review?(gavin.sharp)
Duplicate of this bug: 632617
Attached patch patch v2 (obsolete) — Splinter Review
Attachment #510588 - Attachment is obsolete: true
Attachment #510980 - Flags: review?(gavin.sharp)
Attached patch patch v3 (obsolete) — Splinter Review
more fine-tuning
Attachment #510980 - Attachment is obsolete: true
Attachment #510990 - Flags: review?(gavin.sharp)
Attachment #510980 - Flags: review?(gavin.sharp)
Duplicate of this bug: 632814
Duplicate of this bug: 632944
Attached patch patch v3Splinter Review
updated to tip
Attachment #510990 - Attachment is obsolete: true
Attachment #511171 - Flags: review?(gavin.sharp)
Attachment #510990 - Flags: review?(gavin.sharp)
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
blocking2.0: - → ?
Summary: Status tooltip gets in way / obscures a Find result at the bottom of the page → Link preview gets in way / obscures a Find result at the bottom of the page
Keywords: testcase
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).
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.
blocking2.0: ? → final+
Whiteboard: [softblocker]
Duplicate of this bug: 634224
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..
If this passes reviews, it has implicit a=beltzner
Whiteboard: [softblocker] → [softblocker][pre-approved by beltzner]
Duplicate of this bug: 634287
Duplicate of this bug: 634631
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.
Duplicate of this bug: 635671
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.
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
> 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.
(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.
> By the way Marco, do screen readers pick up the url link preview?

role="status" should cover that.
Summary: Link preview gets in way / obscures a Find result at the bottom of the page → Status panel gets in way / obscures a Find result at the bottom of the page
(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?
(In reply to comment #35)
> Is this the same component as the connecting/waiting/loading status overlay?

yep
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.
(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).
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.
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?
Duplicate of this bug: 636821
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.
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.
(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? :(
Depends on: 171237
Duplicate of this bug: 637182
Duplicate of this bug: 637584
Duplicate of this bug: 637846
Attachment #516214 - Flags: review?(gavin.sharp)
(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?
(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.
(In reply to comment #51)
> Nowhere.
I think that it is not good at all.
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?
(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.
Attachment #510588 - Attachment is obsolete: false
Attachment #510588 - Flags: ui-review?(beltzner)
Attachment #510588 - Flags: review+
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.
Attachment #510588 - Flags: ui-review?(beltzner) → ui-review+
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
Attachment #510588 - Flags: approval2.0+
http://hg.mozilla.org/mozilla-central/rev/000fe7de6636
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [softblocker][pre-approved by beltzner] → [softblocker]
Target Milestone: --- → Firefox 4.0
Duplicate of this bug: 638340
Attachment #516214 - Flags: review?(gavin.sharp)
Attachment #511171 - Flags: review?(gavin.sharp)
Please file a followup bug to fix this properly.
Duplicate of this bug: 638729
Depends on: 638793
Duplicate of this bug: 639325
Duplicate of this bug: 639375
Depends on: 631250
(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.
Duplicate of this bug: 639451
Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0

Verified issue and it's no longer present.
Status: RESOLVED → VERIFIED
Depends on: 640132
Duplicate of this bug: 641307
Depends on: 641240
(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
Duplicate of this bug: 643097
Depends on: 643178
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.
You need to log in before you can comment on or make changes to this bug.