[meta] prevent accessible creation at unsafe time

RESOLVED FIXED

Status

()

RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: surkov, Assigned: surkov)

Tracking

({access, meta})

unspecified
access, meta
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [softblocker])

Comment hidden (empty)
(Assignee)

Updated

8 years ago
Depends on: 625693
(Assignee)

Updated

8 years ago
Depends on: 626660
(Assignee)

Updated

8 years ago
Depends on: 626667
(Assignee)

Comment 1

8 years ago
Asking for blocking. This bug consists in that parts of web page content may randomly disappear from screen readers. This bug may be seen on Firefox 3.6 but it appears more often on Firefox 4. I would like all blocking bugs get fixed to guarantee we never encounter the problem on certain web pages.
blocking2.0: --- → ?

Comment 2

8 years ago
What is the scope of this bug? I really don't see how we can block on this now, given that we're trying to get an RC out in 3-4 weeks.
(In reply to comment #2)
> What is the scope of this bug? I really don't see how we can block on this now,
> given that we're trying to get an RC out in 3-4 weeks.

We estimate about 4 weeks to land these fixes but we'd ask for about 5 weeks if at all possible. This estimate includes the huge bus factor on Alexander for this important work.
I'm calling this a softblocker as this package of work includes hard and soft interdependent blockers. We need to have a contingency for how we can release if the entire work package is incomplete when RC comes.
blocking2.0: ? → final+
Whiteboard: [softblocker]
Assignee: nobody → surkov.alexander
(Assignee)

Comment 5

8 years ago
IMO it should be hardblocker and desirable betaN blocking. This work may be compared to building basement changing and until we finished it the building may crash eventually. That what we observe from time to time when new landings fix existing problems but new ones appear in unpredictable places.

We were forced to start this work since Gecko 2 is too different and required core accessibility changes, we just weren't in time to finish it.
(Assignee)

Updated

8 years ago
Depends on: 629862
(Assignee)

Updated

8 years ago
Depends on: 630001
(Assignee)

Updated

8 years ago
No longer depends on: 630001
(Assignee)

Updated

8 years ago
No longer depends on: 626660
(Assignee)

Updated

8 years ago
No longer depends on: 613058
All dependencies fixed. Nice! Close?
(Assignee)

Comment 7

8 years ago
Theoretically there are cases when we may invalidate children and do not update them what may lead to their caching at unsafe time. But I think it can be marked as fixed.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.