274553 - Blocking iframes either via an extension or userchrome.css breaks find toolbar search

Status: RESOLVED FIXED

(Toolkit :: Find Toolbar, defect)

Description

[TimoT]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041212 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041212 Firefox/1.0+

Blocking iframes either via an extension or userchrome.css breaks find toolbar
search. Symptoms seem to be exactly same as in bug 253502

For me this regressed between 12082004 and 12092004 nightlies.

Reproducible: Always

Steps to Reproduce:
1. Add iframe[src*="adtech"] {display: none !important;} to your userChrome.css
2. Go to http://www.warp2search.net
3. Search for something

Actual Results:  
Search doesn't find anything from the page, if you hit highlight Firefox will
highlight the searched words correctly but find next/previous still do not work.

Expected Results:  
Move the page to the first match and highlight it and move to the next/previous
match when using find next/previous.

Comment 1

[TimoT]

Sorry for the spam, of course I meant userContent.css instead of userChrome.css.

Comment 2

[TimoT]

This error appears in javascript console after trying to search something on a
page with blocked iframe. 

Error: Component returned failure code: 0x80004002 (NS_NOINTERFACE)
[nsIInterfaceRequestor.getInterface]
Source File: 
Line: 209

Comment 3

[Martijn Wargers (dead)]

Attachment: Patch

this was the error message I got at gmail.com, which also suffers from this
bug:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004002 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]"  nsresult:
"0x80004002 (NS_NOINTERFACE)"  location: "JS frame ::
chrome://global/content/findBar.js :: getSelectionControllerForFindToolbar ::
line 209"  data: no] 

Changing the code in that place by using a try..catch solves the bug for me.

Comment 4

[Michael Clackler]

(In reply to comment #3)
> Created an attachment (id=171208) [edit]
> Patch

Nice.  I can confirm that this patch fixes the Trunk problem of the findbar not
working on a page where an add is blocked with userchrome.css.

I can't find the bug, but there is a "sister" bug to this that tracked the
problem back to something done around 12/8 (12/8 build worked, 12/9 build
didn't).  You spoke on MozillaZine saying "I guess the getInterface is in
current trunk builds returning an error, instead of null on an error".  Looking
back to checkins on 12/8, bug 272471 has several changes to the getInterface
routine.

Comment 5

[Michael Clackler]

Requesting blocking 1.1 since this is a regression from 1.0 and a patch exists

Comment 6

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

*** Bug 278477 has been marked as a duplicate of this bug. ***

Comment 7

[Mike Connor [:mconnor]]

Comment on attachment 171208 [details] [diff] [review]
Patch

unless you can tell me _why_ this is failing, and its an expected occurence,
the try/catch is a non-starter.

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

Renominate if a reasoned patch appears. 

Comment 9

[Mike Connor [:mconnor]]

Comment on attachment 171208 [details] [diff] [review]
Patch

Had some time to track this down.  Per bz, if there's a display: none, this is
always going to throw, which is a change since 1.7.  Since docshell throws
where it should, we need to catch the exception.

Comment 10

[Mike Connor [:mconnor]]

*** Bug 287096 has been marked as a duplicate of this bug. ***

Comment 11

[Mike Connor [:mconnor]]

This also breaks sites that do this, plussing this, assign to patch author.

Comment 12

[Asaf Romano (gone)]

Checking in findBar.js;
/cvsroot/mozilla/toolkit/components/typeaheadfind/content/findBar.js,v  <-- 
findBar.js
new revision: 1.5; previous revision: 1.4
done