Note, Geoff filed bug 890252 for the issue. Let's keep discussion there.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/209509
Title:
does not accept textual input
Status in XUL + X
Would you mind please to file separate bug on it (cc Mounir and me)?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/209509
Title:
does not accept textual input
Status in XUL + XPCOM
(In reply to Trevor Saunders (:tbsaunde) from comment #40)
> > > I think the only thing we try to fix here is the infinite recurssion.
> >
> > and code madnness :)
>
> why? the reason for the bug was crashes with a change to atk, so just fixing
> the way we interact with atk should be fine.
the
(In reply to Trevor Saunders (:tbsaunde) from comment #38)
> (In reply to alexander :surkov from comment #37)
> > atk_object_set_name() called inside get_name is a wrong thing we try to
>
> I think the only thing we try to fix here is the infinite recurssion.
and code madnness
atk_object_set_name() called inside get_name is a wrong thing we try to
remove here. It made us fire name change events which is ridiculous I
think. If I get right then ATK implementation internals don't need that
event as long as we override get_name. On the another hand I don't
understand why the
(In reply to Trevor Saunders (:tbsaunde) from comment #34)
> Comment on attachment 726580
> Implement a replacement of atk_object_set_name() which mimics the behavior
> without calling atk_object_get_name()
>
> >+static void
> >+AtkObjectSetName(AtkObject *aAtkObj, const gchar *name)
>
> so, both
Comment on attachment 726580
Implement a replacement of atk_object_set_name() which mimics the behavior
without calling atk_object_get_name()
Review of attachment 726580:
-
::: i/accessible/src/atk/AccessibleWrap.cpp
@@ +147,5 @@
>
Mounir, can you upload a new try build and ask Marco for feedback pls
(since bug 396166 is fixed)?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/209509
Title:
does not accept textua
(In reply to Mounir Lamouri (:mounir) from comment #90)
> Alexander, is there any way I can help? Do you want me to send you a folded
> patch with all changes related to this (this patch might not apply cleanly
> on top af tip)?
yes, it doesn't apply cleanly. something to apply it would be great
(In reply to David Bolter [:davidb] from comment #88)
> I heard from Alex and we can work out the a11y fix/followup separately. Note
> uplift is Tuesday...
We can't ship Firefox breaking hardly the accessibility of HTML
controls. So the fix must be at least on Beta. Having broken HTML file
input o
How is @value attribute implemented on xul:label? They don't create a
native anonymous content for it, correct?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/209509
Title:
does not
(In reply to James Teh [:Jamie] from comment #77)
> (In reply to alexander :surkov from comment #73)
> > Jamie, I think we need your help. Can you take a look please at try build:
> > and say how we should expose the input@type="file" to AT to make it working
> > w
(In reply to n...@parkwaycc.co.uk from comment #80)
> (In reply to alexander surkov from comment #78)
> > Mounir, I assume you use @value attribute on that xul:label. Is it possible
> > to switch to text node instead?
> He can't *switch* to text node because he requires th
(In reply to Marco Zehe (:MarcoZ) from comment #72)
> Comment on attachment 710783
> Patch
>
> This patch removes the read-only input that holds the path and name of the
> chosen file. In a regular nightly build, this is accessible to both JAWS and
> NVDA. In the try build, using the first testcas
(In reply to Mounir Lamouri (:mounir) from comment #75)
> BTW, do we have to expose the anonymous nodes to the accessible document?
it depends, we expose them when we need them
> It
> seems that regarding a11y, it would be as good to simply have one element
> that has some value and can be open (
(In reply to Mounir Lamouri (:mounir) from comment #68)
> (In reply to alexander :surkov from comment #67)
> > Comment on attachment 710783
> > Patch
> >
> > btw, this patch would need a fix on a11y side to make a11y mochitests pass
>
> For the moment, I haven
Comment on attachment 710783
Patch
btw, this patch would need a fix on a11y side to make a11y mochitests
pass
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/209509
Title:
does not a
Comment on attachment 710783
Patch
Mounir, it's better ask Marco to give a try with screen readers. Btw,
it'd be great if you provide a try build.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.
(In reply to JeffreyDecker from comment #24)
> I would like to take on this bug if that's alright.
done, thank you btw.
> Just reading through the
> comments though it looks like it's a little unclear as to how we want to
> refactor to fix the bug.
I think go with solution from comment #21.
> H
(In reply to Trevor Saunders (:tbsaunde) from comment #22)
> or we could do what we do for a bunch of other atk methods reutrning const
> gchar* nd use nsAccessibleWrap::ReturnString() which keeps a static
> nsCString and returns a pointer into its buffer, and so requires caller of
> atk method to
(In reply to Ginn Chen from comment #20)
> > > We need to copy the string to gchar* anyway.
> >
> > yep, just copy the string every time when we were asked. Doesn't sound good?
>
> Actually it's not possible.
> atk_object_get_name() returns const gchar*, caller will not free the return
> value.
(In reply to Karl Tomlinson (:karlt) from comment #57)
> Supporting the new methods for detecting settings is by definition new and
> therefore not thoroughly tested. It seems reasonable to put this through
> the same QA process as any new feature.
It's not a feature that's serious regression. th
Comment on attachment 581750
Updated patch.
serious regression, low risk, running on trunk for several days, no
known regression from this patch. rerequest aurora approval.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubunt
(In reply to Damian from comment #59)
> On a related note, will this fix also address the issue of the File input
> not exposing the aria-label and aria-required attributes that are set on the
> element? At the moment, these seem to be ignored.
No, could you please file new bug?
--
You receive
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #60)
> (In reply to alexander surkov from comment #58)
> > Mounir, would you willing to take a look at this one? I think the approach
> > everybody feels ok is to follow safari's way (it works both for sighted
Mounir, would you willing to take a look at this one? I think the
approach everybody feels ok is to follow safari's way (it works both for
sighted and blind users).
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https:
(In reply to Launchpad from comment #68)
> The committed fix will be awailable in Firefox 3.6 for example with
> Lucid release future?
No, it'll be available for Firefox 10. It's tricky to port it on earlier
releases because it's based on number of other fixes which are likely
not going be porte
inbound land https://hg.mozilla.org/try/rev/81d9a36b80b3
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/602877
Title:
Position is not being updated when atk_text_set_caret_offset is u
(In reply to Neil Deakin from comment #64)
> Comment on attachment 561438
> patch4
>
> Not sure what you're asking me to review but the call to MoveFocus looks ok.
>
> The FLAG_BYMOVEFOCUS won't flag actually do anything here.
Yes, for flags. I removed frameSelection->ScrollSelectionIntoView cal
(In reply to Marco Zehe (:MarcoZ) from comment #61)
> Comment on attachment 561438
> patch4
>
> >+ //gQueue.push(new setCaretOffsetInvoker("link", 1));
>
> Why is this currently commented out?
testing artifact
> And you need caret browsing enabled to see caretmove events, right?
yes
--
Created attachment 561438
patch4
correct patch
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/602877
Title:
Position is not being updated when atk_text_set_caret_offset is used
Stat
Created attachment 561436
patch3
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/602877
Title:
Position is not being updated when atk_text_set_caret_offset is used
Status in The Mozil
32 matches
Mail list logo
