0.4.1 starts search when in form field

[GoogleCodeExporter]

Chromium (linux) 23.0.1271.64 (165188)

Since version 0.4.1, when opening a page and immediately placing the cursor in 
a form field (input / textarea), typing text will capture the input and start a 
search. 

The only workaround is to first click outside of the form field before placing 
the cursor in the field, then the input is not captured.

Original issue reported on code.google.com by olivier....@gmail.com on 25 Nov 2012 at 11:20

[GoogleCodeExporter]

I cannot reproduce, when writing on text-input/textarea the search should never 
start.  This happens in any page you have tried?

Original comment by tokland on 27 Nov 2012 at 1:12

[GoogleCodeExporter]

I did some more testing, it appears that it only happens on some elements that 
were autofocused by a page. It doesn't seem to occur on all pages that use 
autofocus, which makes me think it might be a timing issue (no idea though)...

There are a few places where i can reproduce it 100%, here is one example:

https://bbs.archlinux.org/register.php

Autofocus is placed on the first inputbox, but it triggers a search when typing.

Original comment by olivier....@gmail.com on 27 Nov 2012 at 2:10

[GoogleCodeExporter]

Ok, I see what's going on, It's issue17 again in another disguise: two things 
where happening: 1) this is one of those pages without document.activeElement 
(and boy would I'd love to know why) and 2) at the point of the workaround 
focus/blur, depending on timing, document.readyState = "completed" so the info 
was lost. 

Workaround: set this callback at the very beginning of the content script. 

Will ship in 0.4.2, you can manually apply r166, it works for me.

Original comment by tokland on 27 Nov 2012 at 5:49

• Changed state: Fixed

[GoogleCodeExporter]

Thanks tokland. The strange thing is, i copied the source of a few of those 
faulty pages to a new document and put those online, and the problem didn't 
occur on the copied versions... 

Original comment by olivier....@gmail.com on 27 Nov 2012 at 6:00

[GoogleCodeExporter]

olivier, the timing seemed to be critical, a different server may be enough to 
change the behaviour. If you know some JS and want to play with it, insert:

  console.log("readyState", doc.readyState) 

at setAlternativeActiveDocument, and you'll see what's the load state of the 
page. If it says "complete" the detector hack won't work (because the page was 
already loaded and the focus callback won't fire)

now I call the function at the start, and since the content script is 
configured as run_at@document-start it should always work.

and thanks for reporting!

Original comment by tokland on 27 Nov 2012 at 6:07

[GoogleCodeExporter]

I applied your fix and it indeed fixes the problem, but i have a feeling that 
it prevents chrome-type-ahead from working altogether on problematic sites. For 
instance on a regular page of the site i linked to above:

https://bbs.archlinux.org/

Does type-ahead work for you there?

Original comment by olivier....@gmail.com on 27 Nov 2012 at 10:37

[GoogleCodeExporter]

Indeed, it doesn't work, but it's not related to this commit, it didn't work 
before either. I've seen that body events are not fired, for example if you try 
in the console:

  document.body.addEventListener('keydown', function(ev) { console.log(ev) })

works in all pages, not here. Weird.

Original comment by tokland on 27 Nov 2012 at 10:54

[GoogleCodeExporter]

Hmm interesting, i'm 100% sure though that type-ahead worked on that site until 
very recently (i always use it to jump to subforums quickly), and there haven't 
been any changes on the server side. Anything else in the new type-ahead 
release that could be of influence?

If nothing in type-ahead is causing it, then the only possible cause can be a 
Chromium change...

Original comment by olivier....@gmail.com on 27 Nov 2012 at 11:09

[GoogleCodeExporter]

I tested with Chrome 22.0.1229.79 but it didn't work on 
https://bbs.archlinux.org/ either, keydown events won't fire.

Original comment by tokland on 28 Nov 2012 at 7:50

[GoogleCodeExporter]

I tested a few sites with:

document.body.addEventListener('keydown', function() { console.log('1'); }, 
false);

[Firefox: OK] https://bbs.archlinux.org
[Firefox: OK] http://slashdot.org
[Firefox: OK] https://www.paypal.com

[Chromium: FAIL] https://bbs.archlinux.org
[Chromium: OK] http://slashdot.org 
[Chromium: OK] https://www.paypal.com

All extensions were disabled during the test, so there wasn't any kind of 
interference. Also, bbs.archlinux.org has no other javascripts included on the 
page, it's pure html.

Original comment by olivier....@gmail.com on 28 Nov 2012 at 8:18

[GoogleCodeExporter]

I think it's related to the page being XHTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">

Anyway, it does fire events when set directly to the object "document" instead 
of body, try r167. Let's hope it does not break somewhere else :-)

Original comment by tokland on 28 Nov 2012 at 9:35

[GoogleCodeExporter]

I don't think it's the XHTML, because when i copy the page to another webserver 
it works okay. This makes me wonder if it's some kind of strange http-socket 
condition or something, where Chromium thinks that the page is still not 
completely loaded...

However i applied your diff and that works fine! :-)

Original comment by olivier....@gmail.com on 28 Nov 2012 at 9:49

[GoogleCodeExporter]

If you feel with energy you can try to report the bug (I already opened a 
couple of them, completely ignored ;-))

At least is easy to reproduce.

Original comment by tokland on 28 Nov 2012 at 9:52

[GoogleCodeExporter]

It turns out you were mostly right Arnau. :-)

Here's the cause: 

Apparently XHTML is only parsed as a real XML document when the MIME type is 
set to application/xhtml+xml by the server. When that is the case, you run into 
the situation that document.body is not officially supported in XML, in favor 
of document.documentElement. So when using documentElement (or as you found out 
just document) instead, everything works as intended.

The reason why my copied version of the XHTML page did work, was probably 
because the other server didn't set the correct MIME and sent it as text/html. 
As such it wasn't a proper XML document and document.body was faux-supported.

Original comment by olivier....@gmail.com on 28 Nov 2012 at 10:16

[GoogleCodeExporter]

It makes sense. Incidentally this fix seems to solve the problem reported for 
other pages (http://feferraz.net/). This issue turned out to be very productive 
:-)

Original comment by tokland on 28 Nov 2012 at 10:25