Replacements to page titles are applied twice

[GoogleCodeExporter]

If you go to, e.g., google.com, and apply the replacement "google"->"googlea", 
the new page title will have "googleaa", rather than "googlea". I suspect that 
this is because the title is matched by both relevant XPath tests; in 
foxreplace.js, line 250 and line 318 will both match the page title.

Original issue reported on code.google.com by Zze...@gmail.com on 20 Apr 2012 at 5:36

[GoogleCodeExporter]

Something similar happens with textareas, although oddly enough only for the 
first replacement you make; any replacements after that one are handled 
correctly.

Original comment by Zze...@gmail.com on 20 Apr 2012 at 5:53

[GoogleCodeExporter]

I hadn't noticed this :S But I think that line 318 shouldn't match the page 
title. "/html/body//@title" should match attributes named "title" under the 
body, and the title tag is not an attribute and is not under the body.

Original comment by marc.r...@gmail.com on 20 Apr 2012 at 9:43

• Changed state: Accepted

[GoogleCodeExporter]

Good point. In that case I have no idea what's causing it.

Original comment by Zze...@gmail.com on 20 Apr 2012 at 9:49

[GoogleCodeExporter]

Double substitution in title fixed in r131. I was in fact doing the replacement 
twice, the first one accessing the title property of the document and the 
second through XPath selection.

But no clue about the textarea part yet.

Original comment by marc.r...@gmail.com on 26 Jun 2012 at 6:14

[GoogleCodeExporter]

Well, now I know what is happening to the textarea. It's replaced twice only 
when it has the default value, and this is why:

- The first substitution is applied to its text node (line 296 in r131), which 
contains the default value
- If the textarea still had the default value, this change is propagated to its 
value property; if the value was changed by the user, the change by the first 
substitution is not propagated
- The second substitution is applied to its value property (line 311 in r131), 
which contains the current value

Original comment by marc.r...@gmail.com on 26 Jun 2012 at 6:30

[GoogleCodeExporter]

Last part fixed in r132, just by checking if the textarea still has the default 
value and not applying the second substitution in this case.

Original comment by marc.r...@gmail.com on 26 Jun 2012 at 6:52

• Changed state: Fixed