Auto-populate the text in the Find-in-page textbox with search engine query




9 years ago
3 years ago


(Reporter: mfinkle, Unassigned, Mentored)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [lang=js][lang=java])


(2 obsolete attachments)

From design:

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.), 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).
Assignee: nobody → wjohnston
Posted patch Pre-populate find in page (obsolete) — Splinter Review
Not sure if this is exactly what was wanted or not. It takes terms matching q= from the query params, and fills in find bar every time it is shown. That feels weird to me. If you deleted the term and come back in we write it again. We don't preserve find-in-page terms anyway, so I guess there isn't much lost.
I just realized this morning that this patch should probably also check for search terms in the referrer url. I'll try to fix it up soon.
Comment on attachment 467259 [details] [diff] [review]
Pre-populate find in page

>diff -r e0dfff13f53c chrome/content/browser-ui.js
>--- a/chrome/content/browser-ui.js	Tue Aug 17 17:44:00 2010 -0700
>+++ b/chrome/content/browser-ui.js	Wed Aug 18 17:29:31 2010 -0700
>+  getDefaultSearchTerms: function _findSearchTerms() {
>+    let browser = Browser.selectedBrowser;
>+    let regex = new RegExp("[\\?&]q=([^&#]*)");
>+    let results = regex.exec( browser.currentURI.spec );

Instead of looking for "q" in the url (which is google specific even if many websites does that) my idea at first was to try to see if we could take advantage of the FormSubmit observer.

I mean we could know when a form is submitted thought this, and if we can know from "which" form on the page it came from we could probably check extract the terms from there (I think the way to save the username/password is similar, once those fields has been submitted we don't really know which field is the username so we took the first one _before_ the password and it works great)

Does it makes sense?
Yeah. Sounds good. I'll give it a shot.
OK. Another attempt at this. This uses form submit data if we have it. I dug through submits from Wikipedia, Twitter, Google, Bing, and Yahoo. In most of those cases the search term was the form element directly before the submit button. So the algorithm should:

1.) If there is an input with type=search use its value in the find field
2.) Otherwise look for the submit button and use the element directly before it
3.) Otherwise just use the last element we found
4.) If the users does a search through our urlbar, use that same search term
5.) If we've gotten this far, and have no default search term (for instance, selecting a previous search saved in our history) we parse the url for a few terms

I probably should test this a little more to see if it works. Maybe we should expire the buffer after some time. But I'd appreciate feedback.
Attachment #467259 - Attachment is obsolete: true
This might be nice in Native Fennec, but I'm not working on it.
Assignee: wjohnston → nobody
Product: Fennec Graveyard → Firefox for Android
Whiteboard: [mentor=wesj][lang=js][lang=java]
Is this bug free to take up? Is wesj not mentoring for this?
(In reply to shashank16392 from comment #8)
> Is this bug free to take up? Is wesj not mentoring for this?

Yes it is available, and yes he is mentoring this.

Feel free to assign yourself to this bug.
Ok.. I've checked out latest code using mercurial and built firefox.. How shall I start now?
There are a couple approaches we could try. I think the one from earlier in this bug might be the best. We can register FormAssistant for earlyformsubmit messages here:

and then parse our search terms in a similar way to the patch in this bug (we don't have e10s to worry about, so this SHOULD be much simpler). Then we can just send the data to java with something like

  type: "FormData:Submitted",
  tab: tabId,
  searchTerm: search

The native find in page doesn't listen to any messages yet, but its pretty simple to make it do so (have it implement and register with it like this

Then when its shown we can see if we've got a search term, and if so prefill it. That seems like more than enough to get started. Once its working we can look at making it work well with tabs and multiple page loads and whatnot...

Sound ok?
Is this related only to Firefox on Android? Can't we make it applicable to Firefox on desktop too?

The link - doesn't seem to say anything related to FormAssistant. Am I wrong?

Can we interact further on something like IRC :wesj ?
Whoops. You're right. Here is where I meant:

IRC is fine. I'm in #mobile most of the day. Porting this to desktop would be nice, I agree. We can look at it, but we'll probably need quite a bit of UX input here (and there) as well. I think a prototype implementation for Fennec would probably be a good base to see if this is useful at all first.

Comment 14

6 years ago

I followed the build instructions on the Fennec Wiki, and I *hope* I got all the source good onto my computer. Where do I go from here? I am a total newbie and I posted on other bugs but no one seems to be responding. How do I get involved now?
(In reply to Arjun Nijhawan from comment #14)
> Hello,
> I followed the build instructions on the Fennec Wiki, and I *hope* I got all
> the source good onto my computer. Where do I go from here? I am a total
> newbie and I posted on other bugs but no one seems to be responding. How do
> I get involved now?

Sorry to hear you haven't gotten responses in other bugs, you should feel free to hop in #mobile on if you want to communicate more synchronously.

Wes provided some comments above about how to start working on this bug, so I would start by looking at the parts of the code that he pointed to, then just ask questions when you start to get confused :)

However, Capella just wrote a patch in bug 896764 that implements something very similar to this, so I think we should wait for that to land before starting work here.
fyi - bug 896754 has landed ... so work here can continue :)
Hi, Arjun - Are you still working on this bug?
Mentor: wjohnston
Whiteboard: [mentor=wesj][lang=js][lang=java] → [lang=js][lang=java]

Comment 18

4 years ago
Hey Guys,
I know this is a pretty old bug, but I just got started with Fennec. I have set up the build environment and got my first build. I thought I would head over to mentored bugs section and give them a try.

I got the logic that Wesley here is trying to say. The area I am having trouble with is, registering earlyformsubmit, and then in JAVA registering for "Find in page". Since this is pretty old bugs, the above comments contained line numbers that have changed very much since then.

If you guys can point to an example for registering these events, that would be great ! 

Looking forward to great open source experience !


4 years ago
Flags: needinfo?(wjohnston2000)
Flags: needinfo?(wjohnston2000)
Mentor: wjohnston2000 → michael.l.comella, margaret.leibovic

Comment 20

4 years ago
I want to contribute to fixing this bug.This is my first step so please help me to set up and contribute.
Flags: needinfo?(michael.l.comella)
Margaret, I don't have much context on this bug – do you mind helping out Debojyoti?
Flags: needinfo?(michael.l.comella) → needinfo?(margaret.leibovic)


4 years ago
Attachment #468770 - Attachment is obsolete: true
Flags: needinfo?(margaret.leibovic)
(In reply to Debojyoti Dey from comment #20)
> I want to contribute to fixing this bug.This is my first step so please help
> me to set up and contribute.

Sorry for the slow response! First of all, do you have a build environment set up? If not, you'll want to follow the instructions here:

This might not be a great first bug for you, since it's will take some work to figure out what to do here.

I'm actually not even sure we should implement this, since it seems like it would be tricky to get right, and it would create an inconsistent experience.

Anthony, what do you think?
Flags: needinfo?(alam)
I don't think this is tremendously valuable from a UX perspective anymore. So, I'd say WONTFIX right now.
Flags: needinfo?(alam)
Closing so no one else stumbles into this.
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.