Right now notifications displayed in non-focused windows are causing that window to be focused. This is annoying. We could work to make the doorhangers not focus the other windows, but a simpler solution is to just not show the doorhanger until the window is focused. This has the added benefit of ensuring that the doorhangers entry animation is seen by the user, increasing the likelihood that they will notice it.
Additionally, some existing tests involving extra windows were refactored. I stripped the old tests of their extra windows and created new tests specifically to test the behavior of background windows. These tests were modeled off of the background window tests of PopupNotifications.jsm, which create a new window knowing that this will cause the existing window to be the background, rather than explicitly manipulating the focus of the two windows.
If the percentage basis isn't provided it will be calculated from the ancestors
as before. Note that that algorithm is only valid if the frame's containing
block is the ancestor's content box, which isn't the case for grid items.
So grid layout MUST provide a percentage basis, although the given value may
be NS_UNCONSTRAINEDSIZE for either axis if the value is indefinite.
MozReview-Commit-ID: 7nvAuR43xfM
In order to migrate from buildbot to taskcluster gradually, we read an
external json file to tells the percentage of jobs that must run in
Taskcluster.
MozReview-Commit-ID: K9KZMhe36Cu
--HG--
extra : rebase_source : 9619e5cdb010527538f03b3effe4756fc9574c4e
According to the spec, content from loopback addresses should no longer
be treated as mixed content even in secure origins. See:
- 349501cdaa
- https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy
Note that we only whitelist '127.0.0.1' and '::1' to match Chrome 53 and
later. See:
- 130ee686fa
It is unclear if HTTPS origins should be able to use workers and WebSocket
connections through a loopback HTTP address. They are not supported in Chrome
(whether this is intentional or not is uncertain) so lets just ignore them for
now.
See also: https://github.com/w3c/web-platform-tests/pull/5304
This also disables the menu button and overflow button correctly in
customize mode, and fixes an issues where the overflow button state
would stay 'open' when closing the panel by clicking the button
a second time.
MozReview-Commit-ID: BNTkE6zvv9Q
--HG--
extra : rebase_source : caa6ca5376c0b0e6c5d3190ffaed0b34e5292fb4
This change adds some functions that should be used instead of PR_GetCurrentThread. They both return a PRThread. GetCurrentPhysicalThread does exactly the same thing as PR_GetCurrentThread, but it makes it clearer what you're getting when there are cooperatively scheduled threads running.
GetCurrentVirtualThread returns the same value for all threads in a cooperative thread pool. The actual value it returns is somewhat immaterial.
MozReview-Commit-ID: 4lFwsF2NuzC
This patch aims to speed up the lookup and storage of DisplayItemData objects, by removing a level of indirection and preventing the previously required hashtable lookup in order to access these. Instead it stores an array of pointers on each frame that allows direct access to the DisplayItemData object by dereferencing the frame. Since most frames get either 1 or 2 DisplayItemData objects attached to them a specialized class is used that is of minimal size (2 * sizeof(void)) and that performs well for sizes 1 or 2.
MozReview-Commit-ID: HONKAmpk5H8
Doug Thayer
Mats Palmgren
Wes Kocher
Olli Pettay
Ehsan Akhgari
Timothy Nikkel
Dão Gottwald
Sebastian Hengst
Gijs
Wander Lairson Costa
Birunthan Mohanathas
David Anderson
Matthew Noorenberghe
Luke Wagner
Evelyn Hung
Carsten "Tomcat" Book
Jonathan Kew
Christoph Kerschbaumer
Bill McCloskey
Bas Schouten
Lee Salzman