There is no reason to use nsAtoms*, it's error prone, i.e. the function
can take arbitrary nsAtoms*.
Depends on D15339
Differential Revision: https://phabricator.services.mozilla.com/D15340
This is a big step in order to merge both.
Also allows to remove some very silly casts, though it causes us to add some
ToSupports around to deal with ambiguity of casts from nsIDocument to
nsISupports, and add a dummy nsISupports implementation that will go away later
in the series.
Differential Revision: https://phabricator.services.mozilla.com/D15352
The VisualViewport events are all nice and shiny, but unfortunately not quite
what is needed for the session store.
Firstly, the spec wants the "scroll" event to be fired only when the *relative*
offset between visual and layout viewport changes. The session store however
records the absolute offset and as such is interested in when *that* changes.
Secondly, again as per the spec the events don't bubble, and with the default
DOMEventTargetHelper implementation they don't escape the VisualViewport during
capturing, either. This means that any event listener must be added directly on
the VisualViewport itself in order to capture any events.
This might have been intended because the events use the same names as the
normal "scroll"/"resize" events, and as such you cannot specify separate event
listeners for VisualViewport and non-VisualViewport "scroll" events if both
events end up being dispatched to the same element (you can only try to filter
after the fact by looking at the originalTarget of the event).
At the same time, the VisualViewport is attached to the inner Window, and so
each time you navigate, you also get a different VisualViewport object.
All of this might be totally fine from the perspective of a page script, because
in that case you won't care anyway about what happens when the current page goes
away.
From the session store perspective on the other hand (especially Fennec's non-
e10s session store design), this is rather unfortunate because we don't want to
have to keep registering event listeners
a) manually for each subframe
b) each time the page navigates
The event target chain problem could be solved by letting the scroll events
escape the VisualViewport during the capturing phase (which the spec doesn't say
anything about), but this would mean that any scroll listener attached to a
window/browser/... that uses capturing will now catch both layout and visual
viewport scroll events.
In some cases this might even be beneficial, but in others (e.g. bug 1498812
comment 21) I'd like to specifically decide which kind of scroll event to
capture. Having to look at event.originalTarget to distinguish the two kinds
might be defensible in test code, but in case this distinction would be needed
in production code as well, given the existence of a C++-based filtering helper
in nsSessionStoreUtils for another use case where (scroll) events need to be
filtered, JS-based scroll event filtering might be a bad idea.
Additionally, in any case this wouldn't solve the fundamental conflict between
the spec and the session store about *when* the "scroll" event should be fired
in the first place.
Hence I'd like to introduce a separate set of events with distinct event names,
which will be dispatched according to the requirements of our internal users
(i.e. currently the session store). To avoid potential web compatibility issues
down the road, for now these events will be dispatched only to event listeners
registered in the system group (allowing *all* Chrome event listeners cannot be
done because checking the Chrome status of each event target might be too
expensive for frequently dispatched events).
Differential Revision: https://phabricator.services.mozilla.com/D14046
This changes the semantics of the relative visual viewport offset calculation in
the PresShell slightly, in that a missing root scroll frame will no longer
force the relative offset to zero, even if the visual viewport itself has a non-
zero scroll position [1].
On the other hand, the visual viewport's own relative offset calculations
already work that way today, in that layout and visual viewport scroll positions
are retrieved separately and then subtracted from one another regardless of
whether those values are actually valid or merely a fallback because the
PresShell/scroll frame weren't available.
[1] Though I'm not sure under what circumstances this could really be relevant.
Differential Revision: https://phabricator.services.mozilla.com/D14686
Internally, Gecko stores and updates the *absolute* offset between the visual
viewport and the page, however the spec demands that the scroll event be fired
whenever the *relative* offset between visual and layout viewport changes.
Differential Revision: https://phabricator.services.mozilla.com/D14044
The event rate throttling mechanism is modelled on the logic for "scroll" events
in nsGfxScrollFrame.cpp.
That is
1. When a request to fire an event is posted to the VisualViewport, we create a
new runnable for this and register it with the RefreshDriver. If we already
have a pending runnable, calling VisualViewport->Post...Event() becomes a
no-op.
2. When the RefreshDriver is ready, it executes the runnable, which in turn
fires the actual event and then cleans itself up.
To keep this patch manageable, we simply fire a scroll event every time the
stored visual viewport offset is changed. Because we are storing the absolute
offset of the viewport relative to the page, this behaviour doesn't match the
spec, which demands that scroll events are fired only when the relative offset
between visual and layout viewport changes. We'll fix this up in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D14043
The following APIs are changed.
1. Contains() needs to become contains(). (EnumSet's methods have lowercase names.)
2. Use list constructor rather than "|" like a plain enum.
3. Use operator+= instead of operator|=.
Differential Revision: https://phabricator.services.mozilla.com/D14908
When popping a dirty root, take the shallowest one first (so we reflow from
outer frames first, to avoid potential duplicate reflow of inner frames).
Prevent duplicate roots (to be reworked in a future bug).
Differential Revision: https://phabricator.services.mozilla.com/D9490
As mDirtyRoots will be accessed through a more cohesive API, this patch hides
the storage details (nsTArray) -- but provides almost the same API for now.
Differential Revision: https://phabricator.services.mozilla.com/D9489
All of the removed includes are redundant (i.e. they're #included elsewhere in
the same file).
In most cases, I'm removing the second (redundant) copy of the
#include, except when that copy makes more sense (i.e. if it's in better sorted
order, or if it's paired alongside a closely-associated header while the
earlier copy is not).
Here's the script that I used to generate candidates here -- I ran this in
every subdirectory of layout, on my linux machine (warning, this writes two
files to your /tmp directory):
for FILE in *.h *.cpp; do
nonunique=$(grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | wc -l)
unique=$( grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq | wc -l)
if [[ "$unique" != "$nonunique" ]]; then
echo "$FILE: $nonunique / $unique"
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort > /tmp/nonunique.txt
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq > /tmp/unique.txt
diff /tmp/nonunique.txt /tmp/unique.txt
echo
fi
done
Depends on D13773
Differential Revision: https://phabricator.services.mozilla.com/D13774
The tracking is done using nsAtom origins, similarly to how updates to the
scroll offset are tracked.
Currently, APZ still uses some heuristics to deduce that the main thread
originated a resolution change in some cases, but the intention is to try
to remove those and rely only on this mechanism in the future.
Differential Revision: https://phabricator.services.mozilla.com/D13741
Basically, we shouldn't have blacklist to disable web API. However, the
keypress event behavior changes are not standardized things. Therefore,
if some web developers realize that they need to change their apps when
it's too late for them, Firefox users need to use another browser for
such web apps for several weeks or more, and such things may make the users
switch their default browser. For avoiding such worst scenario, we should
take the blacklists and if we get such compatibility reports, we should
add the domains into the blacklist even in release channel.
Differential Revision: https://phabricator.services.mozilla.com/D13374
Can't land the test-case from bug 1510208 as a crashtest because it needs you to
move the mouse around, and as such it doesn't crash in the crashtest harness.
Differential Revision: https://phabricator.services.mozilla.com/D13054
In each file touched by this commit, there were no mentions of nsAutoPtr
besides the #include.
I verified that the folder layout/base still builds successfully in
non-unified mode after this patch, too. So, none of these files are secretly
using nsAutoPtr and depending on some other .cpp file to provide the header.
Differential Revision: https://phabricator.services.mozilla.com/D12993
When popping a dirty root, take the shallowest one first (so we reflow from
outer frames first, to avoid potential duplicate reflow of inner frames).
Prevent duplicate roots (to be reworked in a future bug).
Differential Revision: https://phabricator.services.mozilla.com/D9490
As mDirtyRoots will be accessed through a more cohesive API, this patch hides
the storage details (nsTArray) -- but provides almost the same API for now.
Differential Revision: https://phabricator.services.mozilla.com/D9489
LocalStorage needs to be exposed in every context except for sandboxes and
NullPrincipals (data: URLs, for instance). But we need to keep data
separate in some scenarios: private-browsing and trackers.
In private-browsing, LocalStorage keeps data in memory, and it shares
StorageEvents just with other origins in the same private-browsing
environment.
For Trackers, we expose a partitioned LocalStorage, which doesn't share
data with other contexts, and it's just in memory. Partitioned localStorage
is available only for trackers listed in the
privacy.restrict3rdpartystorage.partitionedHosts pref. See
nsContentUtils::IsURIInPrefList to know the syntax for the pref value.
This patch re-enables the new behavior of bug 1479964, to set keyCode or
charCode of keypress event whose value is zero to the other's non-zero value.
However, some web apps are still broken with the new behavior. Therefore,
this patch adds a blacklist to keep using our legacy behavior in some specific
web apps.
Note that Google Docs, Gmail and Remember The Milk are reported as broken.
However, I don't see any broken shortcut with Gmail. Therefore, this patch
adds only Google Docs and Remeber The Milk into the blacklist.
Differential Revision: https://phabricator.services.mozilla.com/D10322
In case fuzzers or somebody can catch this in a reproducible way...
I'd be interested in knowing what the hell is going on.
Differential Revision: https://phabricator.services.mozilla.com/D11053
