To avoid hacking around the empty window, and handle the activation issue seen
on Windows / OSX.
MozReview-Commit-ID: oK3T8FKd5n
--HG--
extra : rebase_source : 4d1ed1bae673b3b0e533d7c66303a3cf995fda8b
extra : source : 461021b4bf3ab189babba096584682b2469ce9df
extra : histedit_source : eaa97d93bb4e100e1410471b19585ac125bd828d
console.assert keeps the same semantics as NS_ASSERT in that it doesn't throw an exception,
but a lot of the places code was using it in a way that would be better served by throwing
an exception when the condition is false.
MozReview-Commit-ID: DEF5HSfYO36
This prevents synchronous reflows when opening subviews. This also removes a superfluous invocation of the workaround while the panel is still hidden.
MozReview-Commit-ID: DohLjntVaPU
--HG--
extra : rebase_source : 8cd1b86168aee23d4e75556c2b11baf2c8dd0b9c
We keep the XBL binding around for <content>, <constructor>, and <destructor>. This can
eventually be migrated to a Custom Element once we have platform support, but in the meantime
this is a way to get the many thousands of LOC into a JS class.
MozReview-Commit-ID: 1dCQp527yF9
--HG--
extra : rebase_source : 26b833413bab71168aa15e03f0f3803884be3f6b
extra : amend_source : 150cef6748ca8a9e819de0c674fac5966dd574cf
window.promiseDocumentFlushed will call a callback as soon as a style or layout
flush is not required for the document (which might be immediately). This is a
new ChromeOnly API introduced in an earlier patch in this series.
This patch also removes the now-unneeded BrowserUtils.promiseLayoutFlushed and
BrowserUtils.promiseReflowed methods and infrastructure.
MozReview-Commit-ID: Jv7KoxBXhHG
--HG--
extra : rebase_source : b8c9ae40dbdd0f5587d03e8b7c0833bd94032a78
This patch doesn't introduce new reflows, but adjusts some expected maxCounts
in the test for reflows that were always there but not reliably detected.
MozReview-Commit-ID: 3IV2KBM30rB
--HG--
extra : rebase_source : f15941bc39d879310f4b90c11f16d9793d3f2ced
window.promiseDocumentFlushed will call a callback as soon as a style or layout
flush is not required for the document (which might be immediately). This is a
new ChromeOnly API introduced in an earlier patch in this series.
This patch also removes the now-unneeded BrowserUtils.promiseLayoutFlushed and
BrowserUtils.promiseReflowed methods and infrastructure.
MozReview-Commit-ID: Jv7KoxBXhHG
--HG--
extra : rebase_source : b8c9ae40dbdd0f5587d03e8b7c0833bd94032a78
This fixes regression introduced by hidpi support for wayland in
case devPixelsPerPx is set (bug 1431337).
MozReview-Commit-ID: DOh0aTcxbVG
--HG--
extra : rebase_source : ac3ac449a99e0123b8a64ea36f25d312bb3c4483
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Since bug 1377447 we use EnsurePresShellInitAndFrames for
FlushPendingNotification when textbox gets focused, and
EnsurePresShellInitAndFrames should not trigger any reflows. So in theory,
there is something causes a reflow that we could improve on other platforms.
MozReview-Commit-ID: FAcSZKrv0Fr
--HG--
extra : rebase_source : 727f9ec1803e7046429bc7cf419aed9e4631f971
The reflow was suppressed by bug 1414252, and the expected reflow
for other platforms was dropped in that bug.
MozReview-Commit-ID: HyYhvntOpGx
--HG--
extra : rebase_source : 956e71c28e3840c8fe39da1aea8b5ea2a06081f6
* Let popup code initially measure and place the panel without maxHeight, this ensures alignmentPosition is a reasonable value
* Assign maxHeight from a popuppositioned handler and update the comment explaining the role of the autoPosition property
* Refactor to move the maxHeight calculation into a method on PMV
* panel autoPosition now gets reset to false in popuppositioned (was popupshowing) as the ShowWithPositionedEvent on popupFrame sets it back to true every time
* Update reflow tests with new signatures, and elimination of 1 reflow
* In appMenu reflow test, we must now wait for popupshown before opening subviews
MozReview-Commit-ID: KfHxngnajM3
--HG--
extra : rebase_source : 2918a30f6ecdfded57fb7b93aba3f0479fd4635c
The site security subview is now implemented using the "photonpanelmultiview" element, replacing the last instance of the "panelmultiview" element. The subview features a standard Photon header, hence the connection state icon was moved to the element below it. This makes the styles more similar between the main view and the subview. The connection state styles are now applied using a class name, and the tests have been updated accordingly.
This change required some fixes in the "photonpanelmultiview" implementation to make sure the height of the subview is correct and to allow keyboard navigation back to the main view.
Since the expander button and the permission controls in the main view are not visible anymore after the subview is shown, some code related to focus and hover could be removed as well.
MozReview-Commit-ID: 4nIAPWJPV8k
--HG--
extra : rebase_source : 74d6d769421c0f8521bdfae249b4d111e630a3bd
When running these tests with --verify the places results from
previous test runs can effect tests so give each test run a unique
search term to ensure that they do not.
MozReview-Commit-ID: Lp9YCoUdul5
--HG--
extra : rebase_source : 10178da06863a421ca752970a3f926a61f9c9f43
We have to handle the item overflow after the popup opens in case the positioning has changed, otherwise the measurements would return incorrect values. This causes additional synchronous reflows the first time the popup is opened or after the window is resized.
MozReview-Commit-ID: DEw4oEiEPBa
--HG--
extra : rebase_source : d6f2edb1ca4f668767d17fca67a2ea2e23784f1f
* Harden the new `hideAllViewsExcept()` to not do erroneous things if called when
the binding is already gone.
* Generalize things into `hideAllViewsExcept(thisOne)`:
- Clear `_viewShowing` in there and do the descriptionHeightWorkaround thing
in there too,
- For Photon panels, do all the 'current' attribute setting in there. To show
a panel during transition, I introduced the 'in-transition' attribute.
* I had to make sure not to over-eagerly dispatch 'ViewShowing' events, because
that confuses some,
* Move the temporary panel handling, which contains an ephemeral panelmultiview
instance, internally. This cleans up the hacky, duplicate PanelUI.js code nicely.
* Keep a local copy of `_transitionDetails` to ensure it's still there after transition,
* Harden `_cleanupTransitionPhase()` to only clear the phase that belongs to a
specific transition, _if_ that's passed in as an argument. This resolves any
potential raciness that might occur when `showSubView()` is called again mid-transition.
* Skip the UITour element visibility check when it's inside a panelview, because
too many things need to happen and that check is too simple to be useful in
that case.
MozReview-Commit-ID: 5HpJKs1Ny5j
--HG--
extra : rebase_source : b810e1de2dbd75932a42d68e751fdaecd9fee69a
There have been changes to our Windows infrastructure that cause the
window to be maximized when running tests so the maximize.svg/restore.svg
combination will show restore instead of maximize, though maximize is
still loaded. I think it could be prevented by trying to set the sizemode
attribute a little earlier or not defaulting to maximize in the stylesheet,
but I don't think that's a necessary optimization at this point. We can
just whitelist it.
I also set the intermittentShown flag in case the Windows machines go back
to non-maximized windows.
MozReview-Commit-ID: Gwi0jRBBtGg
--HG--
extra : rebase_source : b92cbd14b873bf8aa0d70e27b140cb0f1a946b74
This started failing when migrating from Windows 8 -> Windows 10. Fix is
tracked in bug 1400357.
MozReview-Commit-ID: HO0AYGjVTGm
--HG--
extra : rebase_source : ff775fdde97c5031e088a4da27e6e0410a6a7c78
This test was previously skipped on Windows 8. This bug is migrating the test over to Windows 10
where we discovered the unused reflow.
MozReview-Commit-ID: FqmgeKc1b9o
--HG--
extra : rebase_source : c7e805edbd0e8df1ac5ac3778dbec0d8d0f0f026
This started failing when migrating from Windows 8 -> Windows 10. Fix is
tracked in bug 1400357.
MozReview-Commit-ID: HO0AYGjVTGm
--HG--
extra : rebase_source : 979f41e192a7e862a446b07c55fdde55e5fbdafd
This test was previously skipped on Windows 8. This bug is migrating the test over to Windows 10
where we discovered the unused reflow.
MozReview-Commit-ID: FqmgeKc1b9o
--HG--
extra : rebase_source : 4c15104b9d63c44dc5c397cb34cf9320797a48a4
The current shutdown handling code is susceptible to deadlocks, since it spins
the event loop while it holds mMonitor, and other main thread methods which
try to acquire mMonitor can be called from code that runs while the event loop
is spinning.
My initial solution was just to release mMonitor before spinning the event
loop, but at this point I think it makes more sense to switch to the
standardized AsyncShutdown routines, which provide better diagnostics and
allow us to avoid one more nested event loop during shutdown.
MozReview-Commit-ID: 1RtFN585IR7
--HG--
extra : rebase_source : 978f3bf7cef73e56b3e1c1c838c2bc6efcefb0c0
extra : amend_source : 2b7c9422004b58ad1d38d7dd705ad446bc47cb23
extra : histedit_source : 7a4e80de7d5aa48e074ea03821bb78e5e287842e%2C92c1119a131adaa33f5691c0e534bb243115817b
Also adds a warning that the test should only be used in debug mode.
MozReview-Commit-ID: 6X8jSz5O2ue
--HG--
extra : rebase_source : 30a52bcceeb19648e59c10ad29e1c71ca2e4e427
This adds a spacer element before the type icon so we don't have to compute its initial margin.
MozReview-Commit-ID: 7dJ38Iwistn
--HG--
extra : rebase_source : a2d140d2906dba0858554c4cd7b9e97f05474518
Also adds a warning that the test should only be used in debug mode.
MozReview-Commit-ID: 6X8jSz5O2ue
--HG--
extra : rebase_source : 67bc022906470695041e37ac1852af1df5b87c90
This commit:
- Makes the window controls have exactly the same height as tabs when the
menubar is hidden, and have the same height as the menubar when it is shown.
This requires us to remove the menubar height before flushing layout in
case it is shown, since we need its original height for the calculation.
- Removes the top margin between the menu bar and the window border
that was present on Windows 10 and makes it apply on Windows 7 only.
The border was causing miscalculations of the window control height,
which could have been handled in browser-tabsintitlebar.js, but since
it's not part of the Photon spec we decide to remove it entirely.
- Makes window control height calculations ignore vertical tabs toolbar
margins. The only margin it has right now is -1px and the calculation
code doesn't work right with negative margins.
MozReview-Commit-ID: HJXxUUJFX8x
--HG--
extra : rebase_source : d5e741cc4ca897ef125ab3e807bc009cd540ade6
This commit:
- Makes the window controls have exactly the same height as tabs when the
menubar is hidden, and have the same height as the menubar when it is shown.
This requires us to remove the menubar height before flushing layout in
case it is shown, since we need its original height for the calculation.
- Removes the top margin between the menu bar and the window border
that was present on Windows 10 and makes it apply on Windows 7 only.
The border was causing miscalculations of the window control height,
which could have been handled in browser-tabsintitlebar.js, but since
it's not part of the Photon spec we decide to remove it entirely.
- Makes window control height calculations ignore vertical tabs toolbar
margins. The only margin it has right now is -1px and the calculation
code doesn't work right with negative margins.
MozReview-Commit-ID: HJXxUUJFX8x
--HG--
extra : rebase_source : fdb5db7e5b410cb45cef054d5cbec41048211f75
The dropmarker gets the urlbar-icon class for consistency with the other URL bar icons. On this occasion, I increased the urlbar-icon padding and removed the margin to match the photon spec. Also added a rudimentary hover effect.
#urlbar-icons is renamed to #page-action-buttons to better reflect its meaning, and because .urlbar-icon is now used outside of this container.
#urlbar-wrapper wrapper isn't needed anymore -- we can just set the switchingtabs attribute directly on #urlbar.
MozReview-Commit-ID: EiuUW71IKgU
--HG--
extra : rebase_source : dcc7753e92073e06278d714a0b5b976d073e75c8
We hit the _adjustFocusAfterTabSwitch function in both the e10s and non-e10s cases, but through
different code paths. This makes the expected stack less specific to account for both cases.
MozReview-Commit-ID: AI4KLUNjUqZ
--HG--
extra : rebase_source : b1fd2df5231e406fe33b7cb4f778c7dc5797b08c
This change in markup was necessary to implement bug 1352063. I have audited all other CSS to make sure other selectors looking for this icon still apply. This was the only one found that needed to be updated.
The change to browser_startup_images.js is not actually a new image that is loaded at startup, but a revert of 767224f031ac (bug 1352063) which removed that section (the test failing due to that section no longer applying should have called out what was necessary to fix this bug).
MozReview-Commit-ID: 6O1iUUjJ0dh
--HG--
extra : rebase_source : a3d41391bda3464fa4c6d4f06638dcfbe8daff3f
This was originally removed from the whitelist when bug 1372689 landed. With
Photon enabled, this image doesn't load at all. Instead of trying to debug
the non-Photon case, we're whitelisting this again because Photon is going
out the door in the next release anyways.
MozReview-Commit-ID: DdN38s3oqST
--HG--
extra : rebase_source : 986c338fb8448f26719ecefd7c4a72db19614622