e915f8fa170f0a669680539289fecc5d58bcf994: Bug 1592739 - Style the browser window's root element with -moz-appearance: dialog on macOS (which is the default). r=ntim draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:54:08 +0000 - rev 2416020
Push 445129 by reviewbot at Tue, 05 Nov 2019 18:54:28 +0000
Bug 1592739 - Style the browser window's root element with -moz-appearance: dialog on macOS (which is the default). r=ntim This is preferable over a hardcoded color because it lets Gecko choose where the window background should come from. We would like the background to be handled by the OS widget, and prevent Gecko from painting a CSS background color. Differential Revision: https://phabricator.services.mozilla.com/D51460 Differential Diff: PHID-DIFF-rmlzjaxkmggty3jx3arj
e482e9ef5e93ee1653ad97d18c7a7cc7406a1ad7: Bug 1592739 - Ignore the background-color CSS value on the window document's root element if that element has a -moz-appearance. r=tnikkel draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:54:05 +0000 - rev 2416019
Push 445129 by reviewbot at Tue, 05 Nov 2019 18:54:28 +0000
Bug 1592739 - Ignore the background-color CSS value on the window document's root element if that element has a -moz-appearance. r=tnikkel For regular elements, whenever -moz-appearance is used, the CSS background is ignored. Root elements were behaving specially, and the background color also needed to be adjusted. For example, for Windows 7, we have the following CSS rule; ``` :root { background-color: transparent; -moz-appearance: -moz-win-borderless-glass; } ``` This change makes the root element more consistent with other elements, so the extra `background-color: transparent` declaration is no longer necessary. This change does not let content documents opt out of forced opaqueness: Root content documents still get an opaque background color from an existing check further down in this method. Differential Revision: https://phabricator.services.mozilla.com/D51459 Differential Diff: PHID-DIFF-vmxggti6ypagzr4jnmrj
2235578c58ce8caccf73d70c5366d9351677ae23: Bug 1592739 - Make nsChildView::WidgetPaintsBackground() return true. r=tnikkel draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:54:03 +0000 - rev 2416018
Push 445129 by reviewbot at Tue, 05 Nov 2019 18:54:28 +0000
Bug 1592739 - Make nsChildView::WidgetPaintsBackground() return true. r=tnikkel On macOS, the OS window always comes with an opaque background for top level windows. This is the case even if Gecko determines the root element of the window to be transparent: Ever since bug 1162649, nsChildView/nsCocoaWindow ignore calls to SetTransparencyMode for top level windows and always stay opaque. Returning true from nsChildView::WidgetPaintsBackground() lets us indicate that we do not need an opaque backstop color to be added at the bottom of the display list. This backstop color would interfere with vibrant -moz-appearance rendering under the new vibrancy model. WidgetPaintsBackground() is only called in one place, in ComputeBackstopColor(): ``` nscolor PresShell::ComputeBackstopColor(nsView* aDisplayRoot) { nsIWidget* widget = aDisplayRoot->GetWidget(); if (widget && (widget->GetTransparencyMode() != eTransparencyOpaque || widget->WidgetPaintsBackground())) { // Within a transparent widget, so the backstop color must be // totally transparent. return NS_RGBA(0, 0, 0, 0); } // Within an opaque widget (or no widget at all), so the backstop // color must be totally opaque. The user's default background // as reported by the prescontext is guaranteed to be opaque. return GetDefaultBackgroundColorToDraw(); } ``` On Windows 7, the widget returns eTransparencyBorderlessGlass from GetTransparencyMode(), which also avoids the backstop color. Differential Revision: https://phabricator.services.mozilla.com/D51458 Differential Diff: PHID-DIFF-vvidkv3a7wivpkjt2il3
792d81abd3f1169086cda6ec4ad588ec48af9006: Bug 1593339 - Remove now-unused vibrancy fill color methods. r=spohl draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:54:00 +0000 - rev 2416017
Push 445129 by reviewbot at Tue, 05 Nov 2019 18:54:28 +0000
Bug 1593339 - Remove now-unused vibrancy fill color methods. r=spohl Differential Revision: https://phabricator.services.mozilla.com/D51457 Differential Diff: PHID-DIFF-45un6korpxmc4pxmrh3l
5f28dee26d3a6724ad79892e16cfe0bd8f734dcc: Bug 1593339 - Stop drawing vibrancy background colors. r=spohl draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:53:58 +0000 - rev 2416016
Push 445129 by reviewbot at Tue, 05 Nov 2019 18:54:28 +0000
Bug 1593339 - Stop drawing vibrancy background colors. r=spohl Drawing vibrancy fill colors was necessary in the past because we were erasing the fill color that was drawn by the system, through our override of the drawRect method of our NSVisualEffectView subclass. However, starting with changeset be263e3d8bdfc0b6c072ffad2736999b9652d036 (from bug 1491445), we no longer override drawRect. Moreover, since the switch to Core Animation, there is no way to clear the system's vibrancy fill drawing. So we don't need to draw the vibrancy fill color any more. In fact, we should stop drawing it, because now we're double-drawing it. The fill color is very translucent so the double-drawing is not visually obvious. Differential Revision: https://phabricator.services.mozilla.com/D51456 Differential Diff: PHID-DIFF-t4at2rypzditgjlizdbu
afd315ff286c62bcba8ebba34a83d80c7e8b6c11: try_task_config for https://phabricator.services.mozilla.com/D51460 draft
libmozevent <release-mgmt-analysis@mozilla.com> - Tue, 05 Nov 2019 18:53:03 +0000 - rev 2416015
Push 445128 by reviewbot at Tue, 05 Nov 2019 18:53:17 +0000
try_task_config for https://phabricator.services.mozilla.com/D51460 Differential Diff: PHID-DIFF-rmlzjaxkmggty3jx3arj
904f3ff50b722352c315350d800f8be29e800c22: Bug 1592739 - Style the browser window's root element with -moz-appearance: dialog on macOS (which is the default). r=ntim draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:52:59 +0000 - rev 2416014
Push 445128 by reviewbot at Tue, 05 Nov 2019 18:53:17 +0000
Bug 1592739 - Style the browser window's root element with -moz-appearance: dialog on macOS (which is the default). r=ntim This is preferable over a hardcoded color because it lets Gecko choose where the window background should come from. We would like the background to be handled by the OS widget, and prevent Gecko from painting a CSS background color. Differential Revision: https://phabricator.services.mozilla.com/D51460 Differential Diff: PHID-DIFF-rmlzjaxkmggty3jx3arj
8affd7b3c027f9112f1063c0b492cf502b0dc09e: Bug 1592739 - Ignore the background-color CSS value on the window document's root element if that element has a -moz-appearance. r=tnikkel draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:52:57 +0000 - rev 2416013
Push 445128 by reviewbot at Tue, 05 Nov 2019 18:53:17 +0000
Bug 1592739 - Ignore the background-color CSS value on the window document's root element if that element has a -moz-appearance. r=tnikkel For regular elements, whenever -moz-appearance is used, the CSS background is ignored. Root elements were behaving specially, and the background color also needed to be adjusted. For example, for Windows 7, we have the following CSS rule; ``` :root { background-color: transparent; -moz-appearance: -moz-win-borderless-glass; } ``` This change makes the root element more consistent with other elements, so the extra `background-color: transparent` declaration is no longer necessary. This change does not let content documents opt out of forced opaqueness: Root content documents still get an opaque background color from an existing check further down in this method. Differential Revision: https://phabricator.services.mozilla.com/D51459 Differential Diff: PHID-DIFF-vmxggti6ypagzr4jnmrj
c141dcfc6443e0a3377ed49650e330700e9f553c: Bug 1592739 - Make nsChildView::WidgetPaintsBackground() return true. r=tnikkel draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:52:54 +0000 - rev 2416012
Push 445128 by reviewbot at Tue, 05 Nov 2019 18:53:17 +0000
Bug 1592739 - Make nsChildView::WidgetPaintsBackground() return true. r=tnikkel On macOS, the OS window always comes with an opaque background for top level windows. This is the case even if Gecko determines the root element of the window to be transparent: Ever since bug 1162649, nsChildView/nsCocoaWindow ignore calls to SetTransparencyMode for top level windows and always stay opaque. Returning true from nsChildView::WidgetPaintsBackground() lets us indicate that we do not need an opaque backstop color to be added at the bottom of the display list. This backstop color would interfere with vibrant -moz-appearance rendering under the new vibrancy model. WidgetPaintsBackground() is only called in one place, in ComputeBackstopColor(): ``` nscolor PresShell::ComputeBackstopColor(nsView* aDisplayRoot) { nsIWidget* widget = aDisplayRoot->GetWidget(); if (widget && (widget->GetTransparencyMode() != eTransparencyOpaque || widget->WidgetPaintsBackground())) { // Within a transparent widget, so the backstop color must be // totally transparent. return NS_RGBA(0, 0, 0, 0); } // Within an opaque widget (or no widget at all), so the backstop // color must be totally opaque. The user's default background // as reported by the prescontext is guaranteed to be opaque. return GetDefaultBackgroundColorToDraw(); } ``` On Windows 7, the widget returns eTransparencyBorderlessGlass from GetTransparencyMode(), which also avoids the backstop color. Differential Revision: https://phabricator.services.mozilla.com/D51458 Differential Diff: PHID-DIFF-vvidkv3a7wivpkjt2il3
2459994fdd07d72a6c00151e1c4e661abb867bc0: Bug 1593339 - Remove now-unused vibrancy fill color methods. r=spohl draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:52:52 +0000 - rev 2416011
Push 445128 by reviewbot at Tue, 05 Nov 2019 18:53:17 +0000
Bug 1593339 - Remove now-unused vibrancy fill color methods. r=spohl Differential Revision: https://phabricator.services.mozilla.com/D51457 Differential Diff: PHID-DIFF-45un6korpxmc4pxmrh3l
77dd8bad2a1e32eb5cfef96621f90375ead60794: Bug 1593339 - Stop drawing vibrancy background colors. r=spohl draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:52:50 +0000 - rev 2416010
Push 445128 by reviewbot at Tue, 05 Nov 2019 18:53:17 +0000
Bug 1593339 - Stop drawing vibrancy background colors. r=spohl Drawing vibrancy fill colors was necessary in the past because we were erasing the fill color that was drawn by the system, through our override of the drawRect method of our NSVisualEffectView subclass. However, starting with changeset be263e3d8bdfc0b6c072ffad2736999b9652d036 (from bug 1491445), we no longer override drawRect. Moreover, since the switch to Core Animation, there is no way to clear the system's vibrancy fill drawing. So we don't need to draw the vibrancy fill color any more. In fact, we should stop drawing it, because now we're double-drawing it. The fill color is very translucent so the double-drawing is not visually obvious. Differential Revision: https://phabricator.services.mozilla.com/D51456 Differential Diff: PHID-DIFF-t4at2rypzditgjlizdbu
35d81fb490715ef55c17016524585c033b7d40cb: try_task_config for https://phabricator.services.mozilla.com/D51459 draft
libmozevent <release-mgmt-analysis@mozilla.com> - Tue, 05 Nov 2019 18:51:56 +0000 - rev 2416009
Push 445127 by reviewbot at Tue, 05 Nov 2019 18:52:10 +0000
try_task_config for https://phabricator.services.mozilla.com/D51459 Differential Diff: PHID-DIFF-vmxggti6ypagzr4jnmrj
a210fe015af1c1e4be17c208335bf742d372d93b: Bug 1592739 - Ignore the background-color CSS value on the window document's root element if that element has a -moz-appearance. r=tnikkel draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:51:53 +0000 - rev 2416008
Push 445127 by reviewbot at Tue, 05 Nov 2019 18:52:10 +0000
Bug 1592739 - Ignore the background-color CSS value on the window document's root element if that element has a -moz-appearance. r=tnikkel For regular elements, whenever -moz-appearance is used, the CSS background is ignored. Root elements were behaving specially, and the background color also needed to be adjusted. For example, for Windows 7, we have the following CSS rule; ``` :root { background-color: transparent; -moz-appearance: -moz-win-borderless-glass; } ``` This change makes the root element more consistent with other elements, so the extra `background-color: transparent` declaration is no longer necessary. This change does not let content documents opt out of forced opaqueness: Root content documents still get an opaque background color from an existing check further down in this method. Differential Revision: https://phabricator.services.mozilla.com/D51459 Differential Diff: PHID-DIFF-vmxggti6ypagzr4jnmrj
b24b3a79538da42319851cc30172ae911914d7a1: Bug 1592739 - Make nsChildView::WidgetPaintsBackground() return true. r=tnikkel draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:51:51 +0000 - rev 2416007
Push 445127 by reviewbot at Tue, 05 Nov 2019 18:52:10 +0000
Bug 1592739 - Make nsChildView::WidgetPaintsBackground() return true. r=tnikkel On macOS, the OS window always comes with an opaque background for top level windows. This is the case even if Gecko determines the root element of the window to be transparent: Ever since bug 1162649, nsChildView/nsCocoaWindow ignore calls to SetTransparencyMode for top level windows and always stay opaque. Returning true from nsChildView::WidgetPaintsBackground() lets us indicate that we do not need an opaque backstop color to be added at the bottom of the display list. This backstop color would interfere with vibrant -moz-appearance rendering under the new vibrancy model. WidgetPaintsBackground() is only called in one place, in ComputeBackstopColor(): ``` nscolor PresShell::ComputeBackstopColor(nsView* aDisplayRoot) { nsIWidget* widget = aDisplayRoot->GetWidget(); if (widget && (widget->GetTransparencyMode() != eTransparencyOpaque || widget->WidgetPaintsBackground())) { // Within a transparent widget, so the backstop color must be // totally transparent. return NS_RGBA(0, 0, 0, 0); } // Within an opaque widget (or no widget at all), so the backstop // color must be totally opaque. The user's default background // as reported by the prescontext is guaranteed to be opaque. return GetDefaultBackgroundColorToDraw(); } ``` On Windows 7, the widget returns eTransparencyBorderlessGlass from GetTransparencyMode(), which also avoids the backstop color. Differential Revision: https://phabricator.services.mozilla.com/D51458 Differential Diff: PHID-DIFF-vvidkv3a7wivpkjt2il3
238ae9c2e22feeacd58559376646b1ffe4833873: Bug 1593339 - Remove now-unused vibrancy fill color methods. r=spohl draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:51:49 +0000 - rev 2416006
Push 445127 by reviewbot at Tue, 05 Nov 2019 18:52:10 +0000
Bug 1593339 - Remove now-unused vibrancy fill color methods. r=spohl Differential Revision: https://phabricator.services.mozilla.com/D51457 Differential Diff: PHID-DIFF-45un6korpxmc4pxmrh3l
47783ebc636062518656a58680983c02a0a05d9d: Bug 1593339 - Stop drawing vibrancy background colors. r=spohl draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:51:46 +0000 - rev 2416005
Push 445127 by reviewbot at Tue, 05 Nov 2019 18:52:10 +0000
Bug 1593339 - Stop drawing vibrancy background colors. r=spohl Drawing vibrancy fill colors was necessary in the past because we were erasing the fill color that was drawn by the system, through our override of the drawRect method of our NSVisualEffectView subclass. However, starting with changeset be263e3d8bdfc0b6c072ffad2736999b9652d036 (from bug 1491445), we no longer override drawRect. Moreover, since the switch to Core Animation, there is no way to clear the system's vibrancy fill drawing. So we don't need to draw the vibrancy fill color any more. In fact, we should stop drawing it, because now we're double-drawing it. The fill color is very translucent so the double-drawing is not visually obvious. Differential Revision: https://phabricator.services.mozilla.com/D51456 Differential Diff: PHID-DIFF-t4at2rypzditgjlizdbu
3ae0b1e244b15ae439724dbe6e8a0af452ce32bd: try_task_config for https://phabricator.services.mozilla.com/D51458 draft
libmozevent <release-mgmt-analysis@mozilla.com> - Tue, 05 Nov 2019 18:50:52 +0000 - rev 2416004
Push 445126 by reviewbot at Tue, 05 Nov 2019 18:51:07 +0000
try_task_config for https://phabricator.services.mozilla.com/D51458 Differential Diff: PHID-DIFF-vvidkv3a7wivpkjt2il3
037689f08af1700d57800bd5b0258d8e90aaac29: Bug 1592739 - Make nsChildView::WidgetPaintsBackground() return true. r=tnikkel draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:50:49 +0000 - rev 2416003
Push 445126 by reviewbot at Tue, 05 Nov 2019 18:51:07 +0000
Bug 1592739 - Make nsChildView::WidgetPaintsBackground() return true. r=tnikkel On macOS, the OS window always comes with an opaque background for top level windows. This is the case even if Gecko determines the root element of the window to be transparent: Ever since bug 1162649, nsChildView/nsCocoaWindow ignore calls to SetTransparencyMode for top level windows and always stay opaque. Returning true from nsChildView::WidgetPaintsBackground() lets us indicate that we do not need an opaque backstop color to be added at the bottom of the display list. This backstop color would interfere with vibrant -moz-appearance rendering under the new vibrancy model. WidgetPaintsBackground() is only called in one place, in ComputeBackstopColor(): ``` nscolor PresShell::ComputeBackstopColor(nsView* aDisplayRoot) { nsIWidget* widget = aDisplayRoot->GetWidget(); if (widget && (widget->GetTransparencyMode() != eTransparencyOpaque || widget->WidgetPaintsBackground())) { // Within a transparent widget, so the backstop color must be // totally transparent. return NS_RGBA(0, 0, 0, 0); } // Within an opaque widget (or no widget at all), so the backstop // color must be totally opaque. The user's default background // as reported by the prescontext is guaranteed to be opaque. return GetDefaultBackgroundColorToDraw(); } ``` On Windows 7, the widget returns eTransparencyBorderlessGlass from GetTransparencyMode(), which also avoids the backstop color. Differential Revision: https://phabricator.services.mozilla.com/D51458 Differential Diff: PHID-DIFF-vvidkv3a7wivpkjt2il3
c343ee5e2b96b24f36c0e648d61853593ce42b6a: Bug 1593339 - Remove now-unused vibrancy fill color methods. r=spohl draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:50:47 +0000 - rev 2416002
Push 445126 by reviewbot at Tue, 05 Nov 2019 18:51:07 +0000
Bug 1593339 - Remove now-unused vibrancy fill color methods. r=spohl Differential Revision: https://phabricator.services.mozilla.com/D51457 Differential Diff: PHID-DIFF-45un6korpxmc4pxmrh3l
eb6cb3723ae2e5e10774e9b8c126d45017a3473d: Bug 1593339 - Stop drawing vibrancy background colors. r=spohl draft
Markus Stange <mstange@themasta.com> - Tue, 05 Nov 2019 18:50:44 +0000 - rev 2416001
Push 445126 by reviewbot at Tue, 05 Nov 2019 18:51:07 +0000
Bug 1593339 - Stop drawing vibrancy background colors. r=spohl Drawing vibrancy fill colors was necessary in the past because we were erasing the fill color that was drawn by the system, through our override of the drawRect method of our NSVisualEffectView subclass. However, starting with changeset be263e3d8bdfc0b6c072ffad2736999b9652d036 (from bug 1491445), we no longer override drawRect. Moreover, since the switch to Core Animation, there is no way to clear the system's vibrancy fill drawing. So we don't need to draw the vibrancy fill color any more. In fact, we should stop drawing it, because now we're double-drawing it. The fill color is very translucent so the double-drawing is not visually obvious. Differential Revision: https://phabricator.services.mozilla.com/D51456 Differential Diff: PHID-DIFF-t4at2rypzditgjlizdbu
(0) -1000000 -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 +1000000 tip