The legacy listener was explicitely avoiding emitting this event for non top-level targets.
It seems like all frontend code listening to will-navigate ignore the event is targetFront.isTopLevel is false,
so it looks like no code would expect these event.
So let's try to avoid emitting them if they aren't used by anyone.
(and can be confusing/buggy in the context of the browser toolbox)
Differential Revision: https://phabricator.services.mozilla.com/D166769
This is the bare minimum that's reasonable to do -- it gives us a simple test of the happy path. The diff is largely indentation changes.
Differential Revision: https://phabricator.services.mozilla.com/D166687
gBrowser.tabs was either redirecting to gBrowser.tabContainer.allTabs or
using the previously cached result. However, most tabContainer code uses
allTabs directly, which was not benefiting from the cache.
Therefore, this patch caches gBrowser.tabContainer.allTabs, and makes
gBrowser.tabs always redirect to it.
Also makes it consistent for gBrowser.tabContainer._getVisibleTabs() and
gBrowser.visibleTabs. In that case both the logic and the cache were in
gBrowser, and tabContainer was redirecting to that, except when gBrowser
hadn't been initialized.
So it's better to have both the logic and the cache in tabContainer.
Differential Revision: https://phabricator.services.mozilla.com/D166962
Picks up a single fix to address a deadlock triggered when attempting to
configure an audio device that has been removed.
Differential Revision: https://phabricator.services.mozilla.com/D166736
RemoteTextureMap::GetRemoteTextureForDisplayList() has enough asserts. The assert in RemoteTextureHostWrapper::CheckIsReadyForRendering() could be removed.
Differential Revision: https://phabricator.services.mozilla.com/D166886
Height of inline elements are considered with current `font-size` and
`line-height`. Therefore, if content in inline elements are taller, the
`background-color` does not fill the bigger content background entirely.
For solving this issue, Chrome handles styles of `<font>` element as
outer-most style. This is reasonable approach, let's follow this.
For solving this issue, we can change the order of `PreservedStyle`s at setting
the preserved styles. Then, `SetInlinePropertiesAsSubAction` is called with
reversed order and apply later style first and applies newer styles to all
content in an element which is previously inserted. Therefore, the `<font>`
element styles should be last elements of `PendingStyles::mPreservingStyles`.
When applying new style, our style editor does not reuse existing `<font>`
element, and this causes writing WPT harder. Therefore, this patch also changes
the applying range of `<font>` style to wrapping existing `<font>` element if
and only if its content is entirely selected.
Unfortunately, this approach cannot get exactly same result as Chrome because we
insert outer-most `<font>` element first, then, try to apply `background-color`,
at this moment, our style editor applies the style to the previously inserted
`<font>` element instead of creating new `<span>` element. This behavior is
required for compatibility in the other cases. Additionally, changing only this
behavior requires a lot of method changes to specify how to handle it. However,
this incompatible behavior may not cause any problems in web apps in the wild.
Therefore, this patch does not solve this incompatible issue. I think that once
we get a bug report caused by this difference, we should redesign how to set
multiple inline styles once.
Depends on D166416
Differential Revision: https://phabricator.services.mozilla.com/D166617
The problem in Yahoo mail is, when you apply new font size to:
```
<div><font size="7">{}<br></font></div>
```
then, when you type text, you'll get:
```
<div><font size="7"><font size="4">abc<br></font></font></div>
```
because `HTMLEditor::CreateStyleForInsertText` does not check ancestors to
apply new style to empty text node which is created by the method for
placeholder. Of course, the other browsers update the existing
`<font size="7">` instead and we should follow it.
However, there are 3 problems:
1. Our editor may adjust insertion point to nearest editable text node if caret
in empty inline elements.
2. Our editor supports increase/decrease font size which have been removed from
`Document.execCommand`, but Thunderbird keeps using it, and that's implemented
with an independent method.
3. Our style editor code does not support applying style to collapsed selection.
Therefore, this patch does:
1. keep create empty text node to apply new style at specific point.
2. give up to use new path if there is preserved font size increment/decrement.
3. separate `HTMLEditor::SetInlinePropertiesAsSubAction` and add new path for
applying style to collapsed range.
Then, `HTMLEditor::CreateStyleForInsertText` can use
`HTMLEditor::SetInlinePropertiesAsSubAction` which supports handling new styles
with existing ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D166416
Make it return a margin from client area to window area, and add an
explicit function to get the size difference.
No behavior change.
Depends on D166428
Differential Revision: https://phabricator.services.mozilla.com/D166431
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
These callers are depending on the existing behaviour which always returns a
thread, and does not respect custom TaskQueues. In the next part, all remaining
callers will be switched to GetCurrentSerialEventTarget.
Differential Revision: https://phabricator.services.mozilla.com/D166606
We aren't likely to try to make these changes any time soon, so cleaning out
these unnecessary methods which just return `this` will simplify things.
I was unable to find any calls to the `.eventTarget` getter in JS, which makes
sense, as the nsIThread type is only really used in JS as a wrapper around the
main thread in older code. Because of that, it has been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D166605
This will help catch issues such as the one from bug 1806751, as we will assert
earlier in the process. This also aligns better with the existing documentation
of the method (which has been updated), which suggests that the method would
assert if called on a thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D166604
This was always being tracked internlly to implement
nsThreadPool::IsOnCurrentThread, however this patch exposes the getter
publicly.
This will be used to assert if GetCurrentSerialEventTarget() is called from a
threadpool thread without a TaskQueue in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D166603
I wrote this while debugging / fixing bug 1806438, and this is kind of
related and needed to fix that bug in one of my machines.
This ensures that all size mode changes go through a central place.
In order to do that, we need to pass whether we need to ShowWindow()
since doing it redundantly in some cases like windows-triggered sizemode
changes would break stuff.
Differential Revision: https://phabricator.services.mozilla.com/D166254
This is a very old and legacy attribute which always had a fuzzy definition.
As of today it was a somewhat alias of "not debugging a local/remote tab".
Differential Revision: https://phabricator.services.mozilla.com/D166904
Ideally, the debugging context should rather be defined by the descriptor
rather than the top target.
On top of that isAddon is only an alias for isWebExtension.
So drop most usages of isAddon and otherwise use isWebExtension.
Differential Revision: https://phabricator.services.mozilla.com/D166903
Originally, we determine whether to show doorhanger by checking if users
have modified autofilled fields. If yes, then we show the credit card update doorhanger.
However, this is not always correct. It is possible the updated data
matches other data in the storage, in that case, we still shouldn't show
the update doorhanger.
This patch updates the behavior to always compare the submmited data and
data in the storage to determine whether to show the update doorhanger.
Differential Revision: https://phabricator.services.mozilla.com/D166316
I wrote this while debugging / fixing bug 1806438, and this is kind of
related and needed to fix that bug in one of my machines.
This ensures that all size mode changes go through a central place.
In order to do that, we need to pass whether we need to ShowWindow()
since doing it redundantly in some cases like windows-triggered sizemode
changes would break stuff.
Differential Revision: https://phabricator.services.mozilla.com/D166254
* Use enumerate(...) instead of manual indexing
* It's safe to modify a list we're iterating on as long as we break out
of the iteration right after the modification.
Differential Revision: https://phabricator.services.mozilla.com/D165053
Basic loop invariant code motion. The impact on execution time is not
totally negligible due to the number of tests involved.
Differential Revision: https://phabricator.services.mozilla.com/D165052
This module defines a single, efficient function to deepcopy a task. It
is faster than deepcopy because it doesn't need to track cycles and
duplicate references that don't make sense for tree (and not graph)
structures.
I measure a speedup > 10% on mach taskgraph tasks --fast >/dev/null.
Differential Revision: https://phabricator.services.mozilla.com/D164789
For example, given that
`surface_rect`: `Box2D((0.0, -1.04904175e-5), (588.99994, 0.0))`
`surface bound`: Box2D((0.0, -512.0), (1024.0, 0.0))
Then doing round_out() after translating the surface_rect with
`-surface_bounds.min.to_vector()` results an empty rect.
We need to make sure that negative origin `surface_rect` is not collapssed.
Differential Revision: https://phabricator.services.mozilla.com/D166887
Alexandre Poirot
Ben Hearsum
Oriol Brufau
Matthew Gregan
sotaro
Cosmin Sabou
Sandor Molnar
Masayuki Nakano
Emilio Cobos Álvarez
Nika Layzell
Mark Banner
Mike Conley
Dimi
Mark Striemer
Gijs Kruitbosch
Adam Vandolder
Geoff Brown
Mike Hommey
serge-sans-paille
Hiroyuki Ikezoe
stransky