Summary:
Currently, `IMEStateManager::SetIMEState` sets hint to the following logic.
- If there is no submit button into form element, set `next`
- If there is submit button, set `search` or `go`
- If there isn't into form element, no hint.
But Chrome sets `next` hint when next focusable element is input that is text
control. So even if there is submit button into form element, we should set
`next` to hint when next focusable element is input that is text/number
control and is in form.
Also, If current focused element isn't in `<form>`, I don't still set hint.
`nsFocusManager::DetermineElementToMoveFocus` may set focus to cross-process
document. So `next` is set when in form and it isn't last element in form.
Reviewers: masayuki
Reviewed By: masayuki
Subscribers: JanH
Bug #: 1474902
Differential Revision: https://phabricator.services.mozilla.com/D12885
--HG--
extra : rebase_source : f9d297416c046d9b718d9ff925006c162d67f286
extra : histedit_source : d8d946deb81f1f961d002e32720eb9a40a91bf64
Summary: To make setting action hint simple, I would like to move it to static function.
Reviewers: masayuki
Reviewed By: masayuki
Bug #: 1474902
Differential Revision: https://phabricator.services.mozilla.com/D24832
--HG--
extra : rebase_source : 730451dd56d0d0d2b8208765cac979f54b9745b1
extra : histedit_source : 5775444e938ec3dfa01e8a7a624dea49b785b307
Actually, there is no public method to get next element/content by tabIndex or
TAB key. So I would like to use GetNextTabbableContent from IMEStateManager.
Differential Revision: https://phabricator.services.mozilla.com/D12884
--HG--
extra : rebase_source : 48fa0bb3cd834e9458ad69be1a08f3f32afd1049
extra : histedit_source : 5ce46db9caf5e970e5ed31c0a9e30bd656242684
nsIPresShell.h is widely included, so this avoids excessively long rebuilds
when MobileViewportManager.h is modified.
Differential Revision: https://phabricator.services.mozilla.com/D26245
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
This preserves the behavior of not having FontFace objects for @font-face rules
in display: none iframes.
Note, however that we may want to always track stylesheets to both not have this
limitation and to fix bug 1471231 & co. But that's a separate bug in any case.
The assertion that is failing ultimately in this bug is not really relevant
anymore, so remove it while at it.
Differential Revision: https://phabricator.services.mozilla.com/D26196
--HG--
extra : moz-landing-system : lando
This bug is happening because we resolve the child of the content generating the
first-line frame inheriting from the XBL marquee's anonymous content (which
isn't affected by the all:inherit rule and thus is non-floating).
Then we go through frame construction, and remove the <marquee> binding, which
makes the anonymous content go away, but don't restyle the children again.
The correct first-letter style without the binding is floating, but we don't
realize while constructing the frame tree.
We do realize of that afterwards though, when reparenting the styles, and
inherit from the right thing, and thus get the right floating style. But there's
nothing saving us now, since the first-letter frame is in-flow already.
The fix is clearing the style of children before removing the binding, the same
way we do before adding it.
FlushStyleBindings removes the current XBL binding. That shuffles the flattened
tree. We need to ensure the styles are gone on children before that to avoid
getting into a bad state.
AutoStyleElement already does that, just slightly too late if there's a
pre-existing binding, so moving it up a bit does the trick.
We do not need to handle onProgressChange64 notifications since the TabChild's
web progress events are filtered through an nsBrowserStatusFilter, which
truncates onProgresChange64 event values to 32-bit integers and then calls
onProgressChange.
Differential Revision: https://phabricator.services.mozilla.com/D25649
--HG--
extra : moz-landing-system : lando
Now that we have access to the RemoteWebProgress from the TabParent and can
construct RemoteWebProgress and RemoteWebProgressRequests in C++, we can
reconstruct the RemoteWebProgress and RemoteWebProgressRequest in the TabParent
instead of RemoteWebProgressManager. This improves the API for nsIBrowser and
RemoteWebProgressManager, removing the need for the
`callWebProgressContentBlockingEventListeners` method in both. It also means we
won't need to implement `callWebProgress*Listeners` for methods on nsIBrowser
and RemoteWebProgressManager for all other nsIWebProgress events.
Differential Revision: https://phabricator.services.mozilla.com/D24942
--HG--
extra : moz-landing-system : lando
WindowGlobalChild.cpp was relying on several headers already included by other
files in its unified build translation unit, but the addition of the
RemoteWebProgressRequest in the next change bumps them into another translation
unit and breaks the build.
The missing `#include` and `using namespace` statements have been added,
allowing builds to succeed.
Differential Revision: https://phabricator.services.mozilla.com/D24937
--HG--
extra : moz-landing-system : lando
Due to adding a new CPP file in the next change, the unified build fails due to
files being shuffled around between translation units. This change fixes the
build.
Differential Revision: https://phabricator.services.mozilla.com/D24810
--HG--
extra : moz-landing-system : lando
The implementation of WebProgressChild.jsm filters all nsIWebProgress events
through an nsBrowserFilter. We need to do this in the TabChild as well, but
TabChild currently only handles onContentBlockingEvent, for which
nsBrowserFilter only calls the underlying listener.
We also unregister the progress listener much earlier in TabChild::Destroy as
this method causes OnStateChange event to be triggered later on, which we are
not interested in capturing.
Differential Revision: https://phabricator.services.mozilla.com/D24805
--HG--
extra : moz-landing-system : lando
There is no specified limit on the number of inputs or outputs, except that
the webidl parameter is unsigned long, but Gecko has an implementation-defined
limit.
Differential Revision: https://phabricator.services.mozilla.com/D25898
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
`nsPICommandUpdater` is a scriptable interface, but nobody refers it from JS,
and it's implemented only by `nsCommandManager`. Therefore, we can get rid
of this interface.
Additionally, `nsCommandManager::Init()` is called only by `nsDocShell`, which
is the only instantiater of the class, and returns error only when given window
is nullptr. Therefore, we can make the constructor take the window instead.
Differential Revision: https://phabricator.services.mozilla.com/D25729
--HG--
extra : moz-landing-system : lando
