Closed Bug 270297 Opened 20 years ago Closed 19 years ago

"search web for" selection ignores newline


(SeaMonkey :: Search, defect)

Not set


(Not tracked)



(Reporter: david, Assigned: elmar.ludwig)



(Keywords: regression, verified1.8)


(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When I select a region containing a newline, then I right-click and choose the
menu option "Search web for <selection>", the search string sent to Google omits
the newline, so Google treats the last word on the first line and the first word
on the second line as a single word.  This is a bug in how Mozilla/Firebird is
constructing the search URL for Google.  Either substituting a space for the
newline (%20), or embedding an actual newline (%0A) will work.

Reproducible: Always
Steps to Reproduce:
1. Select text containing a newline.
2. Right click.
3. Select menu option "Search web for ...".

Actual Results:  
Search is performed but the search string is garbled.

Expected Results:  
Embed newline or space in the search string as a delimiter.
I just noticed the same thing.  I never had much use for "search the web for
<selection>" until Google started accepting addresses and providing links to
maps.  This Google feature, combined with Firefox's search-the-web-for-selection
feature, are a match made in heaven, except that addresses are usually split
across multiple lines and therefore fall prey to this bug.
I often use this feature for web shops that don't host information for their
products. I select the brand and model, rightclick and 'Search Web For'. Some
shops use brand<br/>model, or <h1>brand</h1><h2>model</h2> or so, and I really
think that the 'Search Web For' function should treat the tags between words as
spaces, unless the sequence start with "http://", "ftp://" or "www.". I don't
think that searching for URL's is a reason to keep this feature broken.


if search term qualifies as url: don't insert whitespaces and go to the url directly
else : replace tags with whitespace and search with Google.
*** Bug 303153 has been marked as a duplicate of this bug. ***
*** Bug 313139 has been marked as a duplicate of this bug. ***
(continuing the discussion from bug 313139)

So, can we just change

searchStr = searchStr.replace(/\s*(.*?)\s*$/, "$1");


searchStr = searchStr.replace(/^\s*/, "");
searchStr = searchStr.replace(/\s*$/, "");

as the easiest way to do the intended thing (remove leading and trailing 
whtespace) without the unintended consequences when the text contains newline 
Yes, something like this would work. I have a patch ready.

This was broken by the checkin for bug 221361 (see also the last comment there).
Keywords: regression
Attached patch simple patchSplinter Review
This patch restores two lines that were replaced by the checkin for bug 221361
to fix the newline issues here. The current code using the regular expression
/\s*(.*?)\s*$/ does not work correctly because:

1. The pattern is not anchored at the front, causing a match to start at an
   embedded newline just before the last line in the string (and removing the
   newline in the process).

2. Since "." does _not_ match newlines, the pattern will not match the complete

   string if the string contains embedded newlines, so that whitespace at the
   start is not removed.
Assignee: search → elmar.ludwig
Attachment #200285 - Flags: superreview?(alecf)
Attachment #200285 - Flags: review?(
CC'ing some people from bug 221361 since that was the cause of this bug.
Severity: normal → minor
OS: Windows XP → All
Hardware: PC → All
Comment on attachment 200285 [details] [diff] [review]
simple patch

Attachment #200285 - Flags: superreview?(alecf)
Attachment #200285 - Flags: superreview+
Attachment #200285 - Flags: review?(
Attachment #200285 - Flags: review+
Neil: Can you (or someone else?) please check this into the trunk?

I don't have CVS write access.
I would have checked in earlier, but I was too busy watching TV :-P
Closed: 19 years ago
Resolution: --- → FIXED
You could use just one regexp, I think, by using the m(ultiline) flag:

js> s = "hello\nworld\n"

js> s.replace(/\s*(.*?)\s*$/m, "$1")

Should this bug be fixed for 1.8?

Flags: blocking1.8rc1?
> You could use just one regexp, I think, by using the m(ultiline) flag:

No. If you test this, you will see that trailing whitespace is not removed,
since it matches only on the first line (and adding a "g" modifier would be
even worse):

js> s="hello\nworld\n   "; s.replace(/\s*(.*?)\s*$/m, "$1")+"!"

That said, this _could_ be done in one pattern if you used this:

s.replace(/^\s*([\s\S]*?)\s*$/, "$1");    // note: anchored and no "m" flag

But I am still against using such a pattern, because:

- Trying to be too clever with regular expressions like this makes the code
  hard to read and may even introduce subtle bugs (like seen in bug 221361).
  Not everyone touching this code is an expert in regular expressions...

- Patterns that use non-greedy quantifiers and that are not well constructed
  are often slower than greedy patterns, so I suspect that using two simple
  replace() calls may even be faster here than one more complex call.
Comment on attachment 200285 [details] [diff] [review]
simple patch

Brendan Eich wrote:
> Should this bug be fixed for 1.8?

Trying to get branch approval. This is a simple low risk patch for a
Attachment #200285 - Flags: approval1.8rc1?
Good points -- I'm plusing the bug, its patch should get approved shortly.

Flags: blocking1.8rc1? → blocking1.8rc1+
Attachment #200285 - Flags: approval1.8rc1? → approval1.8rc1+
Keywords: fixed1.8
Verified fixed using yesterday's trunk and branch builds on the testcase from
duplicate bug 313139.
Keywords: fixed1.8verified1.8
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.