This converts the tabmodalprompt binding to a class, to be constructed along side with the element
by TabModalPromptBox.
TabModalPromptBox will keep the instances in a map and pass it to the callers, instead of the element.
The tests and callers can access the class instance by passing the element reference to the map.
Differential Revision: https://phabricator.services.mozilla.com/D15505
--HG--
rename : toolkit/components/prompts/content/tabprompts.xml => toolkit/components/prompts/content/tabprompts.jsm
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
In order to support IA2 live regions with e10s (bug 1322532), text change events sent from the child process to the parent process use sync IPC.
That comes at a slight performance cost: the content process is blocked until the parent returns from sending and handling the event.
However, there is no reason to do this if the event is not for an accessible inside a live region; current clients don't need the sync behaviour outside of live regions.
Differential Revision: https://phabricator.services.mozilla.com/D15183
--HG--
extra : source : 415f827cb9ce211c48b0c6625e917582bc81fd3a
On mingw this causes IIDs to be defined in headers. Those definitions conflict with _i.c files that are included as well. Since we include _i.c anyway, INITGUID is simply not needed.
widl can't handle generating the typelib without explicit importlib() in this case. This should be fixed in widl as well, but using importlib() in this case looks right anyway.
Also add an IsElement check in GetElementFromPoint in the APZ code since I think
the element cast is unsound in presence of Shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D14355
--HG--
extra : moz-landing-system : lando
In order to support IA2 live regions with e10s (bug 1322532), text change events sent from the child process to the parent process use sync IPC.
That comes at a slight performance cost: the content process is blocked until the parent returns from sending and handling the event.
However, there is no reason to do this if the event is not for an accessible inside a live region; current clients don't need the sync behaviour outside of live regions.
Differential Revision: https://phabricator.services.mozilla.com/D15183
--HG--
extra : moz-landing-system : lando
The default implementation of get_accKeyboardShortcut falls back to using the keyboard accelerator if an access key is not available. For XUL menu items, this is not appropriate since the accelerator gets exposed as part of the accessible name already.
The result was a double announcement of the keyboard accelerator on menu items that did not have an access key (underlined letter).
Differential Revision: https://phabricator.services.mozilla.com/D14533
--HG--
extra : moz-landing-system : lando
In bug 1507365, we introduced the ability of nested label children of toolbar buttons to provide the accessible name for a xul:toolbarbutton element. However, the XBL of xul:toolbarbutton causes the creation of a label accessible even if no xul:label child is present, and only the label attribute is being used. The nsIAccessibleText interface on such labels is, however, completely broken. This causes NVDA's mouse tracking, which always uses the deepest nested child, to fail. As a result, when hovering over Hamburger menu items, the announcement would be wrong, e. g., lag one behind the actual button the mouse is hovering over.
To fix this, we only accept xul:label children if they come from real XUL markup, not from the label attribute and the XBL creating the label. This means that some of the test changes from bug 1507365 have to be reverted to accommodate the new old behavior. But the new test for an actual label child still passes.
Differential Revision: https://phabricator.services.mozilla.com/D14469
--HG--
extra : moz-landing-system : lando
This prevents an infinite loop where we go into a child only to find the
nearest hypertext accessible being its parent.
Differential Revision: https://phabricator.services.mozilla.com/D13998
--HG--
extra : moz-landing-system : lando
Turn all const lists and related attributes into cenums, to provide a
vague sense of type safety.
Depends on D11715
Differential Revision: https://phabricator.services.mozilla.com/D11716
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13046
--HG--
extra : moz-landing-system : lando
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
--HG--
extra : moz-landing-system : lando
Creates the HTML Caption accessible from the markup map, but only if it's the first caption. Other caption elements are ignored as before.
This also creates caption accessibles for those captions that have been collapsed to zero height and width via CSS.
Differential Revision: https://phabricator.services.mozilla.com/D12756
--HG--
extra : moz-landing-system : lando
Timothy Guan-tin Chien
Paolo Amadini
Emilio Cobos Álvarez
James Teh
Hiroyuki Ikezoe
Vedant Nevetia
Jacek Caban
arthur.iakab
Jeff Walden
Neil Deakin
Dorel Luca
Marco Zehe
Mark Banner
Csoregi Natalia
Brindusan Cristian
Eitan Isaacson
Sylvestre Ledru
Narcis Beleuzu
Ehsan Akhgari
Tooru Fujisawa
Gabriele Svelto
Andrea Marchesini
Kyle Machulis
Razvan Maries