https://hg.mozilla.org/integration/mozilla-inbound/rev/511ea736284e
--
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:
input type=file does not accept textual input
Status
Comment on attachment 710783
Patch
Marco, could you try this build and tell us if input type='file' are okay
regarding a11y:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mlamo...@mozilla.com-d7c3eda7996a/
Thanks :)
--
You received this bug notification because you are a member
(In reply to alexander :surkov from comment #91)
(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
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)?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
(In reply to alexander :surkov from comment #84)
They don't create a native anonymous content for it, correct?
AFAICT, that's correct.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
(In reply to alexander :surkov from comment #82)
(In reply to n...@parkwaycc.co.uk from comment #80)
So crop doesn't give desired effect on
xul:labelfile:///c:/path-to-file/xul:label
or
xul:descriptionfile:///c:/path-to-file/xul:description
None of those worked.
--
You received this bug
(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 the crop behaviour, but I
Created attachment 710783
Patch
I had to use a xul:label because I needed an ellipsis in the middle of
the text.
Alexander, how would that be regarding a11y? Is using a xul:label a
bad thing?
--
You received this bug notification because you are a member of Desktop
Packages, which is
comment #66)
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.
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-
builds/mlamo...@mozilla.com-b61257dc2541/
--
You received this bug notification
There are two issues:
- the button is now on the left instead of the right, it is the first child
instead of the second;
- the value is shown in a xul:label instead of a html:input which changes a few
stuff especially its role is no longer ENTRY.
--
You received this bug notification because
(In reply to alexander :surkov from comment #70)
(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
BTW, do we have to expose the anonymous nodes to the accessible
document? It seems that regarding a11y, it would be as good to simply
have one element that has some value and can be open (popup state?). I
don't know much about a11y so I might be missing some reasons why we
expose those anonymous
(In reply to Simona B [QA] from comment #32)
When trying to verify this on Firefox 17.0.1 I noticed that after replacing
the permissions.sqlite file in my profile folder I had 2 cookies listed
under the Excetions category in Options-Privacy- History. One of them is
schafmail.de and the other
Aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/609d111f9b9c
Beta:
https://hg.mozilla.org/releases/mozilla-beta/rev/d4646b5033da
Release:
https://hg.mozilla.org/releases/mozilla-release/rev/909cd366fc7d
ESR:
https://hg.mozilla.org/releases/mozilla-esr17/rev/076b31b38565
Comment on attachment 685626
Don't stop when an entry isn't readable
[Approval Request Comment]
Regression caused by (bug #): bug 777072
User impact if declined: if a user has an invalid permission entry in his/her
database, all permissions after that entry will be ignored.
Risk to taking this
I can reproduce the bug. Will work on that.
--
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/1082446
Title:
Firefox 17.0 ignores cookie exceptions
Status in The Mozilla Firefox
Created attachment 685626
Don't stop when an entry isn't readable
The permission manager has a quite un-healty behaviour right now: as
soon as a permission entry isn't readable, it will stop loading the
database and return an error. It happens that this error is ignored
(except in one situation).
Comment on attachment 685626
Don't stop when an entry isn't readable
Regarding file:// handling, I've open bug 815640. I think the right
way to do that is way more risky than this patch. I believe this patch
might be enough for an emergency fix: all permissions will be loaded but
file:// ones are
https://hg.mozilla.org/integration/mozilla-inbound/rev/af301a7b9ecf
--
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/1082446
Title:
Firefox 17.0 ignores cookie exceptions
Status in
This is not related to cookies but to the permission manager. In a
nutshell, the changes we did for the permission manager this summer
broke the hack that was allowing files to have permissions. At load
time, the permission manager is trying to find the principal for
http://scheme:file; which,
(In reply to _ck_ from comment #15)
Since people elsewhere are also reporting problem with IPv6 addresses in
addition to `scheme:file`, might I suggest there is a bug when processing
colons `:` in permissions.sqlite key and/or value data.
Do you have a test case? ie. an IPv6 address I could
F10 is already a shortcut in Firefox and is a common shortcut for GTK
applications. This patch is only changing the behavior of that shortcut
in the GTK version of Firefox to make it more consistent with other GTK
applications. I don't think this should be behind a pref and it should
not bother
https://hg.mozilla.org/mozilla-central/rev/b1603afa2ccb
--
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/161961
Title:
F10-key don't switch focus to menubar in Mozilla Firefox
Status
Comment on attachment 624229
Patch v1
Pushed in m-i with the fix asked in previous comment.
--
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/161961
Title:
F10-key don't switch focus
(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 and
blind users).
By that you mean removing the text field and have only a simple text?
--
You
Webpages should use autofocus instead of |.focus()|. That would solve
this issue. Though, I don't know if we should block |.focus()|, I fear
that could break some websites.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in
26 matches
Mail list logo
