Instead move the check to the focus manager, more similar to how
focus-visible works.
Now nsGlobalWindowInner::ShouldShowFocusRing means "Should we show focus
ring for anything in this window", that is: Have we keyboard-navigated
in this window, or do we have a pref that says that we should always
show focus rings.
Fix some callers appropriately (some of them that were not properly
accounting for the element being focused in the first place...).
Differential Revision: https://phabricator.services.mozilla.com/D75504
ChromeUtils::requestProcInfo was dropping thread names for the process process. This patch restores them and tests that at least *one* thread is named. Unfortunately, at the time of this writing, we cannot assume that *all*
threads are named. Investigation pending.
Differential Revision: https://phabricator.services.mozilla.com/D75420
This doesn't implement manualDoNotDisturb, since we don't want to show the
about:preferences option for suppressing notifications on macOS.
Differential Revision: https://phabricator.services.mozilla.com/D74243
This doesn't implement manualDoNotDisturb, since we don't want to show the
about:preferences option for suppressing notifications on macOS.
Differential Revision: https://phabricator.services.mozilla.com/D74243
It is not obvious that the dict is an internal implementation detail of the
NSPrintInfo, so it was confusing to me that in some places setters are using a
dict but getters are using NSPrintInfo methods. This hopefully makes the code
simpler and easier to understand.
Differential Revision: https://phabricator.services.mozilla.com/D74543
ChromeUtils::requestProcInfo was dropping thread names for the process process. This patch restores them and tests that at least *one* thread is named. Unfortunately, at the time of this writing, we cannot assume that *all*
threads are named. Investigation pending.
Differential Revision: https://phabricator.services.mozilla.com/D75420
Turns out we did have a hook for this already! But it is used to draw or
not inner button styles, so not quite equivalent.
I had to expand the amount of things it applies to because buttons and
such do paint focus indicators in all widgets. This patch could cause
some undesired outlines in some widgets. I hope not (I tried to audit to
the best of my knowledge), but in that case they'd be just more values
to add to the list.
Differential Revision: https://phabricator.services.mozilla.com/D74733
We update the name generation code to dump the files into:
```
OBJDIR/widget/android/GeneratedJNI
```
which are then exported to `mozilla/java`
Differential Revision: https://phabricator.services.mozilla.com/D74720
It's not trivial to split the existing "unified" include declaration
into granular include declarations, so we continue generating a
unified header that can be incrementally abandoned until it can be
jettisoned.
Depends on D58572
Differential Revision: https://phabricator.services.mozilla.com/D58573
This handles the build system bits.
The subsequent patch will restore the "unified"
GeneratedJNI{Natives,Wrappers}.h header files, and will be folded into
this one before landing.
What will still remain is to update the consumers of the .h files (all
the current #include lines) to use the fine-grained imports. At that
time the "unified" header files can be removed entirely.
Differential Revision: https://phabricator.services.mozilla.com/D58572
Turns out we did have a hook for this already! But it is used to draw or
not inner button styles, so not quite equivalent.
I had to expand the amount of things it applies to because buttons and
such do paint focus indicators in all widgets. This patch could cause
some undesired outlines in some widgets. I hope not (I tried to audit to
the best of my knowledge), but in that case they'd be just more values
to add to the list.
Differential Revision: https://phabricator.services.mozilla.com/D74733
We update the name generation code to dump the files into:
```
OBJDIR/widget/android/jni/GeneratedJNI{Natives, Wrappers}
```
which are then exported to `mozilla/jni/natives` and `mozilla/jni/wrappers`
Differential Revision: https://phabricator.services.mozilla.com/D74720
It's not trivial to split the existing "unified" include declaration
into granular include declarations, so we continue generating a
unified header that can be incrementally abandoned until it can be
jettisoned.
Depends on D58572
Differential Revision: https://phabricator.services.mozilla.com/D58573
This handles the build system bits.
The subsequent patch will restore the "unified"
GeneratedJNI{Natives,Wrappers}.h header files, and will be folded into
this one before landing.
What will still remain is to update the consumers of the .h files (all
the current #include lines) to use the fine-grained imports. At that
time the "unified" header files can be removed entirely.
Differential Revision: https://phabricator.services.mozilla.com/D58572
These are reported in telemetry now so it's nice to have more details.
Also some of the entries we're accidentally using a suggested version
as the rule id.
Differential Revision: https://phabricator.services.mozilla.com/D74862
When content length is over 2GB, `WebResponseInfo.contentLength` is negative
value. Use Long.valueOf instead of Integer.valueOf to pass this value.
Differential Revision: https://phabricator.services.mozilla.com/D74586
Unify two separate codepaths that do conceptually identical things. That is,
instead of having the widget code directly dispatch wheel and pinch gesture
events to Gecko, allow APZ to do it as part of it's handling of pinch inputs
when zooming is disabled.
The main difference is that the WidgetSimpleGestureEvent delta values come out
different, because they are based on the macOS event's magnification value,
rather than the (now deprecated) deltaZ value. This is actually better since it
makes the values consistent across platforms and allows removal of some ifdefs.
Differential Revision: https://phabricator.services.mozilla.com/D74640