Re: [tor-bugs] #27503 [Applications/Tor Browser]: Disabling accessibility on Windows breaks screen readers

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#27503: Disabling accessibility on Windows breaks screen readers
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:
                                                 |  pospeselr
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  High                                 |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,      |  Actual Points:
  GeorgKoppen201903, TorBrowserTeam201906R,      |
  tbb-8.5                                        |
Parent ID:                                       |         Points:
 Reviewer:  boklm                                |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by pospeselr):

 Replying to [comment:69 cypherpunks]:
 > Reader's questions (will be removed soon):
 >
 > Can `nullptr` be used?

 No the wine source is C89, not C++11

 >
 https://github.com/pospeselr/wine/commit/b7aec156edc46528e90338bf56bfef0ceaca4217
 > Different Wine-Bug?

 This patch squashes together 18 patches and fixes all the Wine-Bugs as
 well as some un-filed wine bugs preventing screen readers from working.

 >
 https://github.com/pospeselr/wine/commit/7a77bb55dff25254b26309a56575f93586eb0203
 > " inline" instead of "inline "?

 The difference between the two is on purpose.

 > /* FIXME: do we need to handle call_as? */

 We do not, call_as attribute does not appear in the ia2 idl definitions.

 >
 https://github.com/pospeselr/wine/commit/c2d320d79644536ad988bda863b6f689451ee4e0
 > {{{
 >     if (name && (t = find_type(name, namespace, tsENUM)))
 >         return t;
 > }}}
 > Is that coding style acceptable?

 Yes, this section of the patchset was originally written by one of the
 wine devs, but couldn't be applied without the decl_spec_t refactor.

 > Also
 https://github.com/pospeselr/wine/blob/2bf54a0f57566ad7b27194c5f45ccb895cb275ac/tools/widl/header.c#L506

 I don't like it either but code beautification was not the focus of this
 patch set.

 >
 https://github.com/pospeselr/wine/commit/8e043b2f955d76fbf11285e5477d97d89f5065c4
 #diff-e75b8f9447cd0082fdc2e72d13b6f240R36
 > No need to move `*`?

 Fair enough.

 >
 https://github.com/pospeselr/wine/commit/a901af46040902d43d8ed0f70702d0a2f589fb15
 #diff-8905c813ddc5a5cf9d568bae351c24e5R2401
 > `element` here, but `elem` in all other places? Maybe, some better
 names?

 Where possible names were kept the same to minimize the size of the patch
 set. The 'elem' name here is a type_t and used on multiple lines whereas
 the 'element' (which is the name of the 'type' in an array) is a
 decl_spec_t and used in this one place. decl_spec_t has an instance of a
 type_t.

 >
 https://github.com/pospeselr/wine/commit/2bf54a0f57566ad7b27194c5f45ccb895cb275ac
 #diff-8d894b6473d010f03261aa6855bc65fdR64
 > Better naming than adding `2`?

 Perhaps, I'll let the wine devs offer a better alternative.

 >
 https://github.com/pospeselr/wine/commit/26df75e01e1313fd6f8d3fc8cb91ddd5678068dd
 #diff-e75b8f9447cd0082fdc2e72d13b6f240L56
 > Fixed?

 Essentially, this was the culprit behind types being multiply defined in
 the generated typelib. The only remaining duplication is for a specific
 pointer type. This remaining dup is fine because the reason we wish to
 avoid duplicates is so that user defined structs, unions, and enums can be
 compared directly by pointer to determine if the 'thing' is the same type.
 Such a comparison is not needed for pointer types.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27503#comment:73>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs