Closed Bug 436074 Opened 14 years ago Closed 12 years ago

Make Findbar resize-aware, part of the stack and not use a panel to display

Categories

(Firefox for Android Graveyard :: General, enhancement, P2)

Other
Maemo
enhancement

Tracking

(fennec1.0b2+)

VERIFIED FIXED
fennec1.0b1
Tracking Status
fennec 1.0b2+ ---

People

(Reporter: christian.bugzilla, Assigned: mfinkle)

References

Details

Attachments

(3 files, 2 obsolete files)

 
Assignee: nobody → enndeakin
Flags: blocking-fennec1.0+
Priority: -- → P1
Target Milestone: Fennec M6 → Fennec A1
this looks like it's been implemented
Yeah, findbar support was added in bug 431842. Don't think we have a very discoverable way to trigger it, though... bugmorph?
madhava, is there UI for this?
Target Milestone: Fennec A1 → Fennec A2
Keywords: uiwanted
Target Milestone: Fennec A2 → Fennec A3
tracking-fennec: --- → 1.0b1+
Blocks: 477628
Attached image flow wireframe of find-in-page (obsolete) —
Most of the notes for this are in the image, along with the mockups.

A couple of things:

A. an alternate approach would just be to attach the Find-In-Page bar to the titlebar, like all of the notification bars.  Upside - uses the same model (easier for implementation, presumably) and anchors the UI in something the user recognizes.  Downside - eats up screen real-estate for something that is not really of much value to the current task ("yes, I _know_ that's the page I'm currently finding within, thanks.")

B. as for invoking find-in-page, I'm not sure where I'd put an actual button.  I think that, for now, I'd put this in the basic context menu for for the page and, later, we can have a gesture for this, too.

C. something that would BE REALLY GREAT would be, after a person has done a search through a button on the navigation screen (e.g. google, wikipedia, etc.), would be to take that searched-for string and prefill it, automatically, into the Find-in-page field.  It can be highlighted, for easy removal, but this will help round out the use-case of 1. search for "foo", 2. go to search-result page, 3. where on this page is "foo"? (especially if it's hard to read because of the small screen).
Keywords: uiwanted
Just a thought, could an alternate option be to use the smart location bar for find and have "This Page" be an alternate search provider (basically)?
Depends on: 464984
tracking-fennec: 1.0b1+ → 1.0b2+
Current implementation needs to be "resize-aware"
(In reply to comment #5)
> Just a thought, could an alternate option be to use the smart location bar for
> find and have "This Page" be an alternate search provider (basically)?

Christian++

If we do keep the current approach it'd be nice to rework it so it's no an external window ie what gavin did to the awesomebar
Attachment #361630 - Attachment is obsolete: true
I'm wondering if you could start the find UI by entering "/ my text to find" in awesomebar... that's similar to how you activate Quick Find in Firefox on desktop browser.
Assignee: enndeakin → combee
Note: Ctrl-F does bring up findbar, but the UI is outside of stack and doesn't resize well.
Duplicate of this bug: 489471
Priority: P1 → P2
Attached patch WIP 1 (obsolete) — Splinter Review
This is a simple fix that gets the findbar displaying inside the main stack. I'd still like to get rid of the hardcoded "48" when setting the top position.
Assignee: combee → mark.finkle
Attached patch patchSplinter Review
No hard coded heights. Defaults to locating to bottom of content window. We could definitely work on a better UI, but this makes Find functional in Fennec. Use Ctrl+F to open the findbar.
Attachment #374764 - Attachment is obsolete: true
Attachment #374808 - Flags: review?(combee)
Attached image screenshot
Screenshot of the findbar
mfinkle, I didn't see any problems, but I don't yet know about about XUL to understand why you have to add both a vbox and hbox for this.  Let me know and I can R+ this.
(In reply to comment #15)
> mfinkle, I didn't see any problems, but I don't yet know about about XUL to
> understand why you have to add both a vbox and hbox for this.  Let me know and
> I can R+ this.

Oh, the second box is being removed. We only have one box, I was just moving it into the stack.
Comment on attachment 374808 [details] [diff] [review]
patch

Talked with mfinkle at lunch, understand my issue now.  This looks good.
Attachment #374808 - Flags: review?(combee) → review+
Updated bug title to reflect the bugmorph. We can file additional UI tweaks as separate bugs.

http://hg.mozilla.org/mobile-browser/rev/d7c3280e8a4d
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Summary: Find → Make Findbar resize-aware, part of the stack and not use a panel to display
No longer depends on: 464984
Let's get is layed out as in the second wireframe attached to this bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Make Findbar resize-aware, part of the stack and not use a panel to display → Finish find-bar layout
Let's do that in a new bug, though - I'll file.
Status: REOPENED → RESOLVED
Closed: 13 years ago12 years ago
Resolution: --- → FIXED
Summary: Finish find-bar layout → Make Findbar resize-aware, part of the stack and not use a panel to display
this bug has resolved a lot of issues with the find bar, and the new bug will track all cleanup.  Verified with beta3.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.