Updates consumers to the new behavior.
Some consumers are changed to use the "page-icon:" protocol, since it's not
trivial to join the icons table and get a single result out of it. In most cases
the join would return multiple results since a page can have multiple icon payloads.
These consumers for now will return the biggest payload, bug 1347532 will fix
some of them to properly pass a #size=NN fragment.
Note that, even before, these were just "moz-anno:favicon:" uris, and the
payload had to be fetched from the database.
Some other consumers for now just fallback to the largest payload, by passing 0
to GetFaviconURLForPage.
The favicon optimization still happens on the main-thread, bug 1346139 will
handle that problem.
Most of the changes involve handling the modified IconData objects, that now
retain an array of payloads, rather than just one. But note that .ico files are
not yet split into single frames, due to imagelib missing APIs that will be handled
in bug 1337402.
The other changes involve fixing queries to properly join with the new tables.
Finally, note that thanks to the FOREIGN KEYS support, removing from moz_icons or
moz_pages_w_icons will also remove relations from moz_icons_to_pages.
The system only supports square icons, so icons are resized based on their larger side.
This doesn't include new tests, those will be in a following changeset.
MozReview-Commit-ID: JUkpquhpS8y
--HG--
rename : toolkit/components/places/tests/unit/test_svg_favicon.js => toolkit/components/places/tests/favicons/test_svg_favicon.js
extra : rebase_source : fa49c4a81d6ab6b34a2f19ee4175e889a6e9d734
Open webcompat.com in new tab, similar to what "Report Site Issue" button does.
MozReview-Commit-ID: 1ESOY3upHgc
--HG--
extra : rebase_source : 3f55c6798671ad430e59f5954a177a22b4b7642d
Thanks to the previous patch, these tests can now be run on Mac, though they
don't do anything useful there just yet.
MozReview-Commit-ID: 3HyN7ms1EPl
--HG--
extra : rebase_source : c9487790d9c424dd8d21cfb6af927fd4121a15fa
Mostly moved things around to make future tests (using different parameter
sets) easier to write.
Also, all tests are now run on all platforms, but we're expecting nothing to
happen in those cases that were previously skipped.
It will be useful when we add tests that actually need to run on all platforms.
MozReview-Commit-ID: AZTz9lr2eIJ
--HG--
extra : rebase_source : d028ebad59f2eef5591e04f9ca583d264de6b02f
In the past we used a fixed value for the firstPartyDomain of
NullPrincipal, now we derive it from the path of NullPrincipal, so it
will be unique everytime we create it.
The browser.contentPrincpal will report a null prinicpal instead of the actual
content principal if the tab is not loaded. So the SessionStore will collect a
wrong principal for the 'iconLoadingPrincipal', and it will use this wrong
principal to load favicon when session restoring.
To fix this problem, this patch makes the TabState.jsm to collect
'iconLoadingPrincipal' from browser.mIconLoadingPrincipal which will be the
correct principal for loading favicon.
MozReview-Commit-ID: AYUbHFKaG8v
--HG--
extra : rebase_source : 3e2333f18c221d415bd0e26bc416a841344cef2c
The newer Theming API follows the WebExtension install flow, which uses
PopupNotifications to request permission before installation, show progress and
notify upon install completion. This patch makes sure that older LWTs follow that
same flow.
MozReview-Commit-ID: C7X2si0a47J
--HG--
extra : rebase_source : 76f6283818dd69f62c4d59b6b11c5e90d37145a2
Put back in line that was incorrectly removed previously, and add a test.
MozReview-Commit-ID: FEl8fT1uCDm
--HG--
extra : rebase_source : 549b4d9ab9c963ab5a92b81311cffe07fae6953c
The tests in browser_tabCloseProbes.js were closing tabs without waiting for them
to be fully open, and when they're not fully open, closing occurs without animation.
This was intermittently breaking the test for the probe that checks that we add
a count to the right histogram when closing with animation.
MozReview-Commit-ID: 5Qz7mZvtbkB
--HG--
extra : rebase_source : 0d794faebc8e751bfcd15476ae849018dfb1f6c1
Current state:
--------------
Session cookies - those that have no Expires or Max-Age directive, sent as a
header or set via document.cookie - are meant to live for the duration of a
session. SessionStore is a feature that aims to enable users to resume where
they left off last time they closed the browser. So SessionStore will persist
and restore those cookies that the cookie service only keeps in memory.
SessionCookies.jsm registers observers with the cookie service and is thus
notified of cookie additions, deletions, and modifications as-it-happens. It
has its own internal storage that we could easily serialize and write to disk
together with the rest of the session data.
The hangs shown in various profiles stem from the fact that since the inception
of SessionStore as an add-on around Firefox 2, cookies have been tacked to
windows. This means that whenever we collect session data for a specific
window (i.e. tabs, their shistory entries, etc.) we have to iterate *all* its
tabs and *all* their shistory entries to enumerate the hosts contained in that
window. We will then ask the internal cookie store in SessionCookies.jsm to
give us all cookies for these hosts and then store them together with the
window. This way we filter out cookies from tabs/hosts that have no active
documents (BFCache counts as "active").
Changes in this patch:
----------------------
Instead of trying to only retain cookies from “active” documents, i.e. those
contained somewhere in the shistory of a tab, we now simply save all session
cookies of the session. This will surely reduce user complaints about us
"logging them out" too fast because we discard cookies from tabs they
open only once in a while, although those definitely belong to the
browsing session.
Instead of storing the cookies per each window we now have a top-level
"cookies" attribute that is a list of cookies. These get restored whenever we
restore a session. Legacy window.cookies attributes will still be restored to
support older session formats for a while.
The DEFER_SESSION startup mode is active by default when a user choses not to
restore their whole session automatically but they still have one or more
pinned tabs. These pinned tabs are restored automatically and split off of the
rest of the session. The rest can be restored manually if the user chooses to
do so.
In the past, we here extracted and restored only the pinned tabs' cookies from
the last session. This filtering also works against how some sites (e.g.
Google) use session cookies. It also means we have to iterate all windows,
tabs, shistory entries, and cookies to find the data we want.
This patch changes our past behavior so that we now restore only pinned tabs
but all session cookies. So we don't have to filter, and pages will break less
likely. We hereby assume that a user having pinned tabs wants to continue their
browsing session partially, although without Firefox remembering the exact list
of tabs. Or they simply like starting off of a clean slate.
Fischer.json
Rex Lee
Jared Wein
Marco Bonardo
Bob Silverberg
Gerald Squelart
Iris Hsiao
Panos Astithas
Sebastian Hengst
Zibi Braniecki
Olli Pettay
Yoshi Huang
Jonathan Hao
Tim Huang
Andy McKay
Wes Kocher
Mike de Boer
Mark Banner
Doug Thayer
Gijs Kruitbosch
Prathiksha
Mike Conley
Dão Gottwald
kernp25
ffxbld
Carsten "Tomcat" Book
Tim Taubert
Johann Hofmann