See for example
In my experience, such issues
* were never apparent with Safari 2
* are/were apparent with all betas of Safari 3
* are apparent with WebKit nightly r27630 (2007-11-09)
* were probably apparent with other WebKit nightly builds.
If you're not a Google Code 'project member' then you may not see the code to which I refer.
For the project of which I'm a member
there will be many changes required as we move from Google Code to Trac so it would be *really* nice if this class of issue could be resolved.
On closer inspection, it appears that progress has been made.
Using WebKit nightly r27630: the issue is limited to point-and-click selections from such menus. Clicking a selected menu item fails to populate the field with that item; the field remains unchanged.
* use up/down arrow keys
* select the required menu item
* key return (not enter).
AFAIR I reported the bug/symptoms twice to Apple whilst using Safari beta. Twice ... because at one point, the workaround outlined above was effective in only some (not all) drop-down menus that appear to Google Code project members whilst editing Google Code issues. (Now, using WebKit nightly, at a glance: the workaround is effective for all such fields.) Whether it's 'InRadar' I can't say ... AFAIR my reports to Apple were not reflected publicly.
(In reply to comment #1)
> AFAIR I reported the bug/symptoms twice to Apple whilst using Safari beta.
> Twice ... because at one point, the workaround outlined above was effective in
> only some (not all) drop-down menus that appear to Google Code project members
> whilst editing Google Code issues. (Now, using WebKit nightly, at a glance: the
> workaround is effective for all such fields.) Whether it's 'InRadar' I can't
> say ... AFAIR my reports to Apple were not reflected publicly.
They would only be in radar if you used <https://bugreport.apple.com/> to file them. That is currently the best way to file Radar bugs. You may create a free "online" account to log in to bugreport using <https://connect.apple.com/>.
David, thanks. Not present in Radar -- so I must have used the
Safari menu option to 'Report Bugs to Apple…'.
Months ago, probably around the times of the first and second public betas of Safari (AFAIR the second appeared to be slightly better than the first).
OT from this particular issue, a general question:
* How often (if ever) do bugs reported via that route find their way across to WebKit Bugzilla?
(In reply to comment #3)
> * How often (if ever) do bugs reported via that route find their way across to
> WebKit Bugzilla?
I don't know. It's best to file WebKit-related issues here on <http://bugs.webkit.org/> so that open source contributors as well as Apple may see them. If you have an issues that are related to Safari itself or lower-level frameworks, it's best to file them on <https://bugreport.apple.com/>. Here's a blog post about how to tell when to use each one. (Just make you best guess when filing the bug.)
What does it require to join a project on Google Code? It looks like that is required in order to debug this issue.
(In reply to comment #4)
> What does it require to join a project on Google Code? It looks like that is
> required in order to debug this issue.
1) For membership, a Gmail username is required
2) At a project home page, click 'Join project' to reveal the fuller answer to this FAQ
I guess the project that should be most amenable to a request to join will be
Or, try any WebKit-friendly project.
http://code.google.com/hosting/search?q=WebKit&projectsearch=Search+Projects reveals a few :-)
I'm one of the engineers that works on open source project hosting at code.google.com. I found some work-arounds for the apparent causes of the problem. These might be useful details for your project.
1. I had been using onmousedown attribute on a <tr>. That seemed to never get that event in Safari 3. The first work-around was to move the onmousedown into the <td>'s inside that <tr>.
2. With the onmousedown attribute on the <td>s in the first column of the table, detection of the event seemed unreliable and the text field being typed in seemed to randomly lose focus. After looking through the webkit bugzilla, I found that moving the mouse even a few pixels while clicking triggered the problem and prevented any further onmousedown's from being detected. The workaround was to listen for onmouseup instead.
3. Our onmousedown handler had returned false to prevent further processing of the event which have caused a blur event. With no onmousedown, I have no way to prevent the blur event. Rather than use onblur on the <input> where the user had been typing, I now listen for focus events for every other element on the page.