WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
15132
REGRESSION (
r15963
-
r15970
): Heading text not placed in VoiceOver Item Chooser with Safari 2 and WebKit Nightly
https://bugs.webkit.org/show_bug.cgi?id=15132
Summary
REGRESSION (r15963-r15970): Heading text not placed in VoiceOver Item Chooser...
Benjamin Hawkes-Lewis
Reported
2007-09-02 02:19:13 PDT
Load WebKit Nightly with Safari 2, go to the URL, and turn on VoiceOver (command + F5). Press control + option + down until you reach HTML Content, then press shift + control + option + down to interact with the HTML content. Press ctrl + option + down and you should be moving through the webpage itself. Press ctrl + option + I to open the Item Chooser menu. It includes some items called "heading" but it does not include any of the heading text. If you do the same thing in Safari 2 with its original WebKit, the heading text is included in the Item Chooser menu. Is this not a regression?
Attachments
Test case
(129 bytes, text/html)
2007-09-02 12:10 PDT
,
David Kilzer (:ddkilzer)
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Benjamin Hawkes-Lewis
Comment 1
2007-09-02 02:25:49 PDT
For reference, here's how I currently have VoiceOver configured. 1. In Keyboard & Mouse within System Preferences, find the Keyboard Shortcuts tab and select "press Tab to move the focus between all controls". 2. In Universal Access within System Preferences, tick "Enable access for assistive devices". 3. Then Open the VoiceOver Utility, select the Navigation tab. 4. Tick all but the last item under General Navigation. 5. Tick only "VoiceOver cursor tracks keyboard focus" and "Keyboard focus tracks VoiceOver cursor" under the Cursor Tracking tab. 6. Tick both checkboxes under Text Selection Tracking.
David Kilzer (:ddkilzer)
Comment 2
2007-09-02 07:05:56 PDT
Safari 2.0.4 with a Nightly WebKit build is not officially supported. Do you know if the bug is present with the Safari 3 Public Beta and a Nightly WebKit build? That would be a more serious issue.
Benjamin Hawkes-Lewis
Comment 3
2007-09-02 07:31:45 PDT
What do you mean by "supported"? I don't see any statement to that effect that bug reports must use Safari 3 not 2 at:
http://webkit.org/quality/reporting.html
or
http://webkit.org/quality/bugwriting.html
I can't easily test Safari 3, since as a web developer I need Safari 2 for testing webpages at work and I can't run the two side-by-side. However, the problem also exists in the latest development version of OmniWeb (which uses a recent nightly build). Since the Item List is independent of Safari, it seems pretty clear to me that this is a WebKit bug not a Safari bug.
David Kilzer (:ddkilzer)
Comment 4
2007-09-02 08:42:09 PDT
(In reply to
comment #3
)
> What do you mean by "supported"? I don't see any statement to that effect that > bug reports must use Safari 3 not 2 at: > >
http://webkit.org/quality/reporting.html
> or >
http://webkit.org/quality/bugwriting.html
By "officially supported" in
Comment #2
I meant that Apple does not officially support a combination of Safari 2.0.4 and WebKit nightly builds, so the chances of this getting fixed (if the issue is NOT in WebKit) are highly unlikely. (Technically speaking, the WebKit nightly builds are not officially supported at all, but they're a great way to test and to develop fixes.) Another way to define "not officially supported" is that you can't call AppleCare and expect them to resolve issues found with Safari 2.0.4 and a WebKit nightly build. Again they're for development and testing purposes only. Having said that, you may draw the conclusion that the Safari 3 Public Beta with a WebKit nightly build isn't officially supported either, and you would be correct. However, this configuration is MUCH CLOSER to what will eventually be shipped, and thus is more valuable to know if this bug happens in that configuration. It would also be valuable to know if the Safari 3 Public Beta (without using a WebKit nightly build) is affected by this bug.
> I can't easily test Safari 3, since as a web developer I need Safari 2 for > testing webpages at work and I can't run the two side-by-side. However, the > problem also exists in the latest development version of OmniWeb (which uses a > recent nightly build). Since the Item List is independent of Safari, it seems > pretty clear to me that this is a WebKit bug not a Safari bug.
It is possible to have both installed, although I only recommend doing this if you understand the instructions:
http://trac.webkit.org/projects/webkit/wiki/UsingSafari2WithSafari3PublicBetaInstalled
David Kilzer (:ddkilzer)
Comment 5
2007-09-02 09:09:35 PDT
(In reply to
comment #4
)
> By "officially supported" in
Comment #2
I meant that Apple does not officially > support a combination of Safari 2.0.4 and WebKit nightly builds, so the chances > of this getting fixed (if the issue is NOT in WebKit) are highly unlikely.
My hidden assumption above (that this is not a WebKit issue) lies in the fact that other known incompatibilities exist between Safari 2 and later WebKit nightly builds:
http://trac.macosforge.org/projects/webkit/wiki/Known%20incompatibilities%20between%20open-source%20WebKit%20and%20Safari
This issue "feels" similar, but I don't know for sure whether it is or not.
Benjamin Hawkes-Lewis
Comment 6
2007-09-02 10:48:04 PDT
Right, thanks for the tip. I can now confirm that this is also an issue both with Safari 3 Beta and Safari 3 Beta with the latest WebKit nightly.
David Kilzer (:ddkilzer)
Comment 7
2007-09-02 11:49:17 PDT
Confirmed regression using a local debug build of WebKit
r25341
with Safari 3 Public Beta v. 3.0.3 (522.12.1) on Mac OS X 10.4.10 (8R218). Works as described in
Comment #0
using Safari 2.0.4 (419.3) with original WebKit on 10.4.10. NOTE: You must use
Comment #1
to set up VoiceOver in order to test.
David Kilzer (:ddkilzer)
Comment 8
2007-09-02 12:10:38 PDT
Created
attachment 16182
[details]
Test case * STEPS TO REPRODUCE 1. Set up VoiceOver per
Comment #1
. 2. Turn on VoiceOver (Cmd-F5). 3. Load the test page. 4. Hit Ctrl-Option-I to bring up the "Item Chooser" menu. * EXPECTED RESULTS An entry called "A unique heading" should show up in the Item Chooser menu. Also, when moving the box over "A unique heading" the words "a unique heading" should be spoken. * ACTUAL RESULTS An entry called "heading" shows up in the Item Chooser menu. Moving the box over "A unique heading" speaks nothing. * REGRESSION See
Comment #7
.
David Kilzer (:ddkilzer)
Comment 9
2007-09-02 12:34:58 PDT
Autospade says: Works:
r15963
Fails:
r15970
David Kilzer (:ddkilzer)
Comment 10
2007-09-02 12:38:24 PDT
Revisions
r15965
-
r15967
are most likely related, with
r15967
affecting headings directly.
http://trac.webkit.org/projects/webkit/changeset/15965
http://trac.webkit.org/projects/webkit/changeset/15966
http://trac.webkit.org/projects/webkit/changeset/15967
David Kilzer (:ddkilzer)
Comment 11
2007-09-02 12:39:14 PDT
<
rdar://problem/5456785
>
David Harrison
Comment 12
2007-09-03 09:40:42 PDT
Committed revision 25351 via the Radar report.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug