1289157 - remove eSurvivingInUpdate flag from Accessible class

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P5)

Description

[alexander :surkov (:asurkov)]

no longer needed, just remove it, see [1]

[1] https://dxr.mozilla.org/mozilla-central/rev/4c05938a64a7fde3ac2d7f4493aee1c5f2ad8a0a/accessible/generic/Accessible.h#1012

Comment 1

[Nick Fox [:njfox]]

Attachment: Bug 1289157 - Removed eSurvivingInUpdate flag and corresponding function

Review commit: https://reviewboard.mozilla.org/r/116798/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/116798/

Comment 2

[alexander :surkov (:asurkov)]

Comment on attachment 8843038 [details]
Bug 1289157 - Removed eSurvivingInUpdate flag and corresponding function

https://reviewboard.mozilla.org/r/116798/#review118430

::: accessible/generic/Accessible.h:1033
(Diff revision 1)
> -    eSurvivingInUpdate = 1 << 8, // parent drops children to recollect them
>      eRelocated = 1 << 9, // accessible was moved in tree
>      eNoXBLKids = 1 << 10, // accessible don't allows XBL children
>      eNoKidsFromDOM = 1 << 11, // accessible doesn't allow children from DOM
>      eHasTextKids = 1 << 12, // accessible have a text leaf in children
>  

could you bump indexes down please and adjust kStateFlagsBits value correspondingly too

Comment 3

[Nick Fox [:njfox]]

Comment on attachment 8843038 [details]
Bug 1289157 - Removed eSurvivingInUpdate flag and corresponding function

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/116798/diff/1-2/

Comment 4

[alexander :surkov (:asurkov)]

Comment on attachment 8843038 [details]
Bug 1289157 - Removed eSurvivingInUpdate flag and corresponding function

https://reviewboard.mozilla.org/r/116798/#review118764

thanks, that should work

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Autoland can't push this until the patch has r+ from someone with Level 3 access in MozReview.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #5)
> Autoland can't push this until the patch has r+ from someone with Level 3
> access in MozReview.

presumably my access level is not 3 or did I set r+ incorrectly somehow? what ways to resolve the issue?

btw, what level 3 access in mozreview stands for and does autoland runs a try server build to make sure we are in good shape at least the patch compiles?

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Level 3 commit access. Though in your case, I'm betting it's because your hg email address differs from your BMO one.
http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/install.html#manually-associating-your-ldap-account-with-mozreview

Comment 8

[alexander :surkov (:asurkov)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #7)
> Level 3 commit access. Though in your case, I'm betting it's because your hg
> email address differs from your BMO one.

It seems same, hg's and this one are both <[e-mail]>

> http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/
> install.html#manually-associating-your-ldap-account-with-mozreview

I run ssh reviewboard-hg.mozilla.org mozreview-ldap-associate, created a new mozreview API keys (the existing one is 'hidden' in bugzilla prefs). How can check if it worked out?

Comment 9

[alexander :surkov (:asurkov)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7197abf8c984aa4c582e3ad7c9793a4bd4ecbe44
Bug 1289157 - remove eSurvivingInUpdate flag from Accessible class, r=surkov

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/7197abf8c984