Bug 59053 – REGRESSION (r83386): Typing in WSJ.com search field doesn't clear placeholder text

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Adele Peterson]

Typing in WSJ.com search field doesn't clear placeholder text

Bisecting indicates this was caused by http://trac.webkit.org/changeset/84039

Steps to reproduce:
- Go to http://www.wsj.com
- Click in the search field on the upper right, with the placeholder text "News, Quotes, Companies, Videos" (I don't think this is a placeholder attribute)
- type

It should clear the placeholder text.

[Adele Peterson]

<rdar://problem/9305025>

(In reply to comment #0)
> (I don't think this is a placeholder attribute)

It is not.

[Dimitri Glazkov (Google)]

I am having trouble reproducing. I am on Version 5.0.4 (6533.20.27, r84360). Click on the search field immediately clears the placeholder text. Is this what should be happening?

[Adele Peterson]

I can get this to work sometimes, but most of the time it fails.  When it fails, if I click over "Quotes", I end up entering text in the middle of that word.

[Dimitri Glazkov (Google)]

(In reply to comment #4)
> I can get this to work sometimes, but most of the time it fails.  When it fails, if I click over "Quotes", I end up entering text in the middle of that word.

Morrita-san and I will try to repro again today. It would be great to have a better reduction.

The revision you mentioned looks rather doubtful to be the culprit in any of this, since the WSJ site doesn't travel any of the affected code. They don't use <summary>/<details>.

[Dimitri Glazkov (Google)]

I think this bug has more to do with the racing in loading of scripts. According to the code in http://sj.wsj.net/djscript/bucket/NA_WSJ/page/0_0_WH_0001_public/provided/j_global_slim/version/20110419230428.js:

1) focus event triggers loading of http://s.wsj.net/djscript/j_networkHat-201134.js
2) when the script is loaded, a function "searchFieldOnFocus" from this script is called
3) the function clears the value of the input.

Since I can't reproduce the bug in Chromium or WebKit nightly, I can't tell exactly where this chain breaks down, but it's definitely not the r84039.

[Dimitri Glazkov (Google)]

Created attachment 90551 [details]
Beautified WSJ script that contains misbehaving code.

Thanks. I was now able to reproduce the bug with a build of a revision earlier than r84039.

Further testing suggests that this was caused by r83386.

[Dimitri Glazkov (Google)]

(In reply to comment #9)
> Further testing suggests that this was caused by r83386.

Ha! Still me :)

Are you using just standard WebKit nightly and Safari 5 on Snow Leopard or some other magic thing to repro this? I am flying blind, since I can't repro locally.

[Dimitri Glazkov (Google)]

(In reply to comment #10)
> (In reply to comment #9)
> > Further testing suggests that this was caused by r83386.
> 
> Ha! Still me :)
> 
> Are you using just standard WebKit nightly and Safari 5 on Snow Leopard or some other magic thing to repro this? I am flying blind, since I can't repro locally.

I am able to reproduce now. The trick is to rest the cursor over the search box a bit before clicking.

[Dimitri Glazkov (Google)]

I am a bad boy. Fix coming up.

[Dimitri Glazkov (Google)]

Created attachment 90629 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 90629 [details]
Patch

Clearing flags on attachment: 90629

Committed r84587: <http://trac.webkit.org/changeset/84587>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Dimitri Glazkov (Google)]

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