Mock: https://folio.googleplex.com/chrome-ux-specs-and-sources/Chrome%20browser%20(MD)/Secondary%20UI%20Previews%20and%20specs%20(exports)/Preview#%2FP%20-%20javascript_03.png%3Fz=width

Doesn't seem Mac-specific, unless this is somehow already done elsewhere and just about MacViews plumbing?

Ah, yes - not Mac specific. I just forgot to update the OS checkboxes after filing from a Mac :).

Load balancing

Unless I've missed something, it looks like the only remaining thing for these dialogs is to remove the close button. The rest of the dialog is using all the same delegates and metrics as most other dialogs.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bd896a76aff2bf494f9c30fab96150754292c91f

commit bd896a76aff2bf494f9c30fab96150754292c91f
Author: Allen Bauer <kylixrd@chromium.org>
Date: Thu Oct 26 19:20:44 2017

Remove close button on JavaScript prompt/alert/confirm dialogs.

Bug:  683346 
Change-Id: I40332d006a6ede04fdc27b94c65eb9a2edf3bb7b
Reviewed-on: https://chromium-review.googlesource.com/739952
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511916}
[modify] https://crrev.com/bd896a76aff2bf494f9c30fab96150754292c91f/chrome/browser/ui/javascript_dialogs/javascript_dialog_views.cc
[modify] https://crrev.com/bd896a76aff2bf494f9c30fab96150754292c91f/chrome/browser/ui/javascript_dialogs/javascript_dialog_views.h

I think there's some text styling that I'll be covering as part of two other dialogs (that have the same root cause). I can keep this until it's ready.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6314cbc42d31aaf3cadd302cfb0ec31dfa7f0578

commit 6314cbc42d31aaf3cadd302cfb0ec31dfa7f0578
Author: Peter Boström <pbos@chromium.org>
Date: Fri Nov 10 00:46:57 2017

Style views::MessageBoxView for Harmony.

Introduces CONTEXT_MESSAGE_BOX_BODY_TEXT and styles it like
CONTEXT_BODY_TEXT_LARGE and STYLE_SECONDARY under Harmony. This
specifically styles the JavaScript dialogs.

Bug:  chromium:652015 ,  chromium:652017 ,  chromium:683346 
Change-Id: I846c33736cfffb368105ea1cd49c2a8079e20b14
Reviewed-on: https://chromium-review.googlesource.com/759409
Reviewed-by: Trent Apted <tapted@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#515378}
[modify] https://crrev.com/6314cbc42d31aaf3cadd302cfb0ec31dfa7f0578/chrome/browser/ui/views/harmony/harmony_typography_provider.cc
[modify] https://crrev.com/6314cbc42d31aaf3cadd302cfb0ec31dfa7f0578/ui/views/controls/message_box_view.cc
[modify] https://crrev.com/6314cbc42d31aaf3cadd302cfb0ec31dfa7f0578/ui/views/style/typography.h

The NextAction date has arrived: 2017-11-10

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ed6a1c0ddd26fff0ce52d6e1b89799ca0f6906d0

commit ed6a1c0ddd26fff0ce52d6e1b89799ca0f6906d0
Author: Peter Boström <pbos@chromium.org>
Date: Tue Nov 14 02:22:46 2017

Make ScrollView in MessageBoxView fill the dialog.

Previously the ScrollView scrollbar and vertical borders did not span
across the entire horizontal dialog, with this change the scroll bar is
all the way to the right, and scrollview top/bottom dividers span past
dialog insets.

The insets are instead applied to the ScrollView contents, so the text
content is still inset properly. This Harmonizes dialogs that make use
of MessageBoxView, specifically JavaScript prompt/alert dialogs.

Bug:  chromium:683346 
Change-Id: Icbaa18b26a22975ba3fcf9d2b584416636cba07f
Reviewed-on: https://chromium-review.googlesource.com/767450
Commit-Queue: Peter Boström <pbos@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516145}
[modify] https://crrev.com/ed6a1c0ddd26fff0ce52d6e1b89799ca0f6906d0/ui/views/controls/message_box_view.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/98abed2d448f0316becdec4118fc81e0ce6121a7

commit 98abed2d448f0316becdec4118fc81e0ce6121a7
Author: Peter Boström <pbos@chromium.org>
Date: Tue Nov 14 02:33:27 2017

Reduce MessageBoxView ScrollView height.

The current max view made the dialog very tall and is significantly
taller than the Harmony spec. This specifically addresses JavaScript
prompt dialogs.

Bug:  chromium:683346 
Change-Id: Icb5776023598a3b3388e0f586ff364c84cd9b267
Reviewed-on: https://chromium-review.googlesource.com/767591
Commit-Queue: Peter Boström <pbos@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516152}
[modify] https://crrev.com/98abed2d448f0316becdec4118fc81e0ce6121a7/ui/views/controls/message_box_view.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/977ebe428e23759cdcdb5ea7e342f210604c17f0

commit 977ebe428e23759cdcdb5ea7e342f210604c17f0
Author: Peter Boström <pbos@chromium.org>
Date: Fri Nov 17 03:18:22 2017

Add conditional titlecase to JavaScript dialogs.

Adds titlecase title strings for window.prompt, alert, on-reload
and on-close dialogs.

Bug:  chromium:652015 ,  chromium:652017 ,  chromium:683346 
Change-Id: I197a8ad11d95d0d4f7671bba81f671d8c45206c2
Reviewed-on: https://chromium-review.googlesource.com/773907
Reviewed-by: Bret Sepulveda <bsep@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517271}
[modify] https://crrev.com/977ebe428e23759cdcdb5ea7e342f210604c17f0/components/app_modal_strings.grdp

Attaching screenshot @ 150dpi on Windows 10.

Deleted: javascript-dialog-150hdpi.png 174 KB

	javascript-dialog-150hdpi.png 174 KB View Download

Alan, it's not clear from the mock that the attribution for the page triggering the alert should be removed.

Here are the current strings:

https://cs.chromium.org/chromium/src/components/app_modal_strings.grdp?type=cs&q=app_modal_strings.grdp&sq=package:chromium&l=7

To always match the mock we'd need to remove IDS_JAVASCRIPT_MESSAGEBOX_TITLE(/_IFRAME) and only use the strings that are currently under _NONSTANDARD_URL:

"This page says"
"An embedded page on this page says"

Instead of:

"www.google.com says"
"An embedded page at www.google.com says"

Is the URL removal intentional or that just one of them are showing in the mock?

Also note that we're not consistent w/r/t calling it "this page" vs "this site" in the titles.

If this is fine I think the dialogs put together is done.

We're not very consistent among dialogs/bubbles that have scrollable content in the middle of the dialog. Some adhere to the desired MD padding around the client area. Others extend the scrollable region horizontally to the left and right edges of the dialog.

What is the rule here? Visually, extending the scrollable region to the edges of the dialog looks better. However, this presents some interesting programmatic challenges since many of the dialogs include the padding all around the inside edge by default. In fact, in most cases, when the middle content area is *not* scrollable or doesn't have enough content to require scrolling, the padding is respected.

c17: 

Disregard the guidance to remove the attribution in the title. This was an attempt to make these titles less vulnerable to spilling over into 2 lines. The current design is WAI: 

"www.google.com says"
"An embedded page at www.google.com says"

c18: 

We should be consistent when possible because we regard 'page' and 'site' to mean 2 different things. Where is the inconsistency? The image in c16 is using the correct string. 

c19:

The current guidance is to have scrollable content extend to the edges, assuming that it's contents adhere to the desired 16px MD padding. 

If the programmatic challenges are unsolvable in a reasonable amount of time, I'd recommend allowing the scrollable content to adhere to the padding around it. In other words, not go edge-to-edge. 

The amount of impressions a dialog makes without a scrollable area is larger than impressions with a scrollable area so we should design for that. 

We use title casing for titles on macOS but can we prevent this awkward capitalization in the interim?

Deleted: Screen Shot 2017-12-19 at 4.31.42 PM.png 24.5 KB

	Screen Shot 2017-12-19 at 4.31.42 PM.png 24.5 KB View Download

That could be in interesting test for Chrome's translation system.. I haven't seen m64 translations for these yet. The concern would be if there's some language that phrases it differently. Like, "Said by www.w3schools.com". There's also a related string that  goes

"An Embedded Page at jsfiddle.shell.net Says" -- should that be "Says" or "says"?

Deleted: Screen Shot 2017-12-20 at 2.56.57 pm.png 61.3 KB

	Screen Shot 2017-12-20 at 2.56.57 pm.png 61.3 KB View Download

Should we cover C21 by lowercasing Says and breaking the rules or rephrase it to say something like "Dialog From www.w3schools.com"?

+bettes@ for comment 22/23.

E.g. we could use something like:

* Dialog From www.w3schools.com
* Dialog From an Embedded Page at www.w3schools.com

If we end with the URL I think that looks less funky?

+1. Putting the URL at the end will help with this. Let's go with: 

"From www.foobar.com"
"From an embedded page at www.foobar.com"

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/677891d2365eda05ec79bf5bc25f05f6187ec5a4

commit 677891d2365eda05ec79bf5bc25f05f6187ec5a4
Author: Peter Boström <pbos@chromium.org>
Date: Wed Jan 03 06:56:45 2018

Update JavascriptAppModalDialog titles.

On titlecase systems the "www.example.com Says" heading is awkward, so
to end with the URL these are being replaced by "From www.example.com"
and corresponding "From an Example Page at www.example.com".

Bug:  chromium:683346 
Change-Id: Ie520328276259f787541a02e39ed725687c1dff6
Reviewed-on: https://chromium-review.googlesource.com/846249
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526642}
[modify] https://crrev.com/677891d2365eda05ec79bf5bc25f05f6187ec5a4/components/app_modal/javascript_dialog_manager_unittest.cc
[modify] https://crrev.com/677891d2365eda05ec79bf5bc25f05f6187ec5a4/components/app_modal_strings.grdp

Fixed, the rest of Alan's input were tangental/separate discussions to the dialog implementation.