Change - Theme tab-modal prompts to look good in Metro

VERIFIED FIXED in Firefox 28

Status

defect
P1
normal
VERIFIED FIXED
7 years ago
5 years ago

People

(Reporter: ally, Assigned: rsilveira)

Tracking

({feature})

unspecified
Firefox 28
x86
Windows 8.1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [block28] feature=change c=Content_features u=metro_firefox_user p=3)

Attachments

(9 attachments, 7 obsolete attachments)

194.31 KB, image/png
Details
134.84 KB, application/pdf
Details
207.29 KB, image/png
Details
47.92 KB, image/png
Details
44.01 KB, image/png
Details
32.81 KB, image/png
Details
9.32 KB, patch
mbrubeck
: review+
Details | Diff | Splinter Review
421.34 KB, application/x-zip-compressed
Details
339.84 KB, application/x-zip-compressed
Details
Reporter

Description

7 years ago
No description provided.

Updated

7 years ago
OS: Mac OS X → Windows 8 Metro
Component: General → Theme
Keywords: uiwanted
Summary: implement prompts → Metro theming for alert/prompt dialogs
Whiteboard: [metro-mvp] → [metro-mvp][LOE:1]
Assignee: nobody → ywang
Keywords: uiwanted

Comment 1

7 years ago
I worked on tab-modal prompts for Firefox desktop, and I'm happy to work with Yuan on the design and implementation of this for Metro.
Status: NEW → ASSIGNED

Updated

7 years ago
Blocks: 831978
Whiteboard: [metro-mvp][LOE:1] → [metro-mvp][LOE:1] feature=work
Summary: Metro theming for alert/prompt dialogs → Work - Metro theming for alert/prompt dialogs
Whiteboard: [metro-mvp][LOE:1] feature=work → feature=work
Depends on: 836878

Updated

6 years ago
Summary: Work - Metro theming for alert/prompt dialogs → Work - Metro theming for javascript alerts
Priority: -- → P5
After walking through different types of alerts, I have two suggestions for alerts.

1. When an alert is prompted, we need to freeze other functions on the browser. That means, the users cannot do anything on FX browser until the users make a decision on the alert prompt. (also recommended by MSDN: "Don't use a dialog if the user can ignore the message.")

FYI, on Android Firefox, the users can tap outside of the prompt to dismiss the dialog. On Chrome on Android, the browser is totally freezed.

2. We need a snap view version of alert dialog.

In terms of the theme, I think currently what we have looks fine. The buttons have the same style with the ones for info bar.
Priority: P5 → P4
Priority: P4 → P2
The old implementation of prompts looked good but didn't work very well; the new implementation (which is actually just using desktop Firefox's tab-modal prompt implementation) works pretty well but looks bad.

I'm hijacking this bug to track progress toward making our tab-modal prompts look good in metro.
Summary: Work - Metro theming for javascript alerts → Work - Theme tab-modal prompts to look good in Metro
Summary: Work - Theme tab-modal prompts to look good in Metro → UX Work - Theme tab-modal prompts to look good in Metro
Priority: P2 → P1
I discussed my proposal with Ally and Frank today. 
The proposal is: 
For v1, treat tab modal dialogs as window modal dialogs. The dialog pops up on top of the page, requiring the users to make a choice. Edge swipe should not be enabled in this case.

For v2, once we start to implement the Tab view concept (switching tabs is going to be on a separate page), it makes better sense to differentiate tab modal and window modal dialogs.

Frank suggested to provide an option to prevent repeated dialogs popping up in a loop. So I will add that to the V1 design. 

Lastly, we do need a snap view version of the dialog. Right now, the buttons are totally cut out. We need to fix that.
No longer blocks: 831978
Blocks: 886563
No longer blocks: 886563
Blocks: 892575
Depends on: 866304
Discussed with Tim today about whether to treat tab modal dialogs as window modal for V1.

Update: Tim will work on implementing the tab modal dialog for V1. If it does turn out to be easier to implement our dialogs as window-modal, it's fine to keep tab modal as window modal from a UX perspective for v1.

When a tab modal dialog is shown, interacting with the browser is totally allowed (e.g. switching tabs, adding new tabs, etc) but interacting with the page is not, for example bookmarking, pinning, using auto-complete.

Note from Tim: the Tab View concept for V2 won't add additional efforts to this work.
Reporter

Comment 6

6 years ago
sounds like we've worked out what we need for the preview & v1. Perhaps we should parent this bug elsewhere to track v2 efforts?
Whiteboard: feature=work → feature=work [preview-triage]
Once bug 886563 lands, I think UX should take a look at the various metro prompts and provide input on the way they look and feel. We can use this bug for tracking the results (i.e. when UX feels that the prompts look good enough for v1 we can close this bug)

We can file new bugs for v2 issues.
Whiteboard: feature=work [preview-triage] → feature=work
No longer depends on: 866304
Tomorrow I'll attach the current WIP patch for styling metro prompts, and pictures of what the prompts look like with patch applied.

CC'ing Dolske so he can be part of the subsequent discussion
In bug 895457 we are getting bitten by the fact that the dialog/prompt markup is not at all responsive and content is clipped in snapped view. This is presumably an issue in desktop also though much more of an edge case. Maybe this bug is where we should put a new markup template in place with CSS to allow the contents to be legible at the window sizes metro needs to support?

Updated

6 years ago
Whiteboard: feature=work → feature=work, [preview]
Hi Tim, this is the first version of tab modal dialog design. I basically applied the same style as the old crash report design. 

Let me know what you think. And Stephen, feel free to post your thoughts on the design here.
This looks awesome!

I think the hardest part will be making the prompts responsive to the OSK, but most of this seems very doable. I'll post back when I've got a WIP patch.
(In reply to Yuan Wang(:Yuan) – Firefox UX Team from comment #11)
> Let me know what you think. And Stephen, feel free to post your thoughts on
> the design here.

Nice! Looks good to me.

Updated

6 years ago
Whiteboard: feature=work, [preview] → feature=work, [preview][l10n]
Assignee: ywang → rsilveira
QA Contact: jbecerra
Summary: UX Work - Theme tab-modal prompts to look good in Metro → [MP] Change - Theme tab-modal prompts to look good in Metro
Whiteboard: feature=work, [preview][l10n] → [preview] [l10n] feature=change c=Content_features u=metro_firefox_user p=3
Rodrigo - thanks for taking a look at this bug! I'll try to provide a brain dump here so you don't have to do as much investigative work up front.

Going through the pages of the design in order:
  - There is code at [1] that keeps the prompts at 60% of the width of the browser. This works in metro as well as desktop, so we shouldn't have to add any metro-specific logic for making prompt width responsive
  - Similarly, scroll bars should appear in appropriate places and we shouldn't have to add any metro-specific code to make them work properly. Some things don't work perfectly (e.g. bug 895507), but they are not metro-specific issues
  - The interaction between the OSK and prompts is covered in bug 883930. I think it would be reasonable to do that work separately in bug 883930 if this bug is too complex as is.
  - All prompts in metro are supposed to show the prompt origin. To accomplish that, modify this line from [2] - 'if (!topPrincipal.equals(promptPrincipal))' to include a check for nsIWinMetroUtils.immersive. Once bug 904230 lands, it will be as easy as adding '|| Services.metro.immersive' to the 'if' check.
  - The <hr> that shows up in the new design between the prompt title and prompt body will probably have to be added at [3] and shown conditionally if 'Services.metro.immersive' is true (same trick as for showing the prompt title above)
  - The buttons should already support 'enter' to select and 'tab' to switch between them, so there should be no additional work necessary there
  - To make the default button orange: We already have a CSS class that makes default buttons orange in metro [4], we just need to apply it to the default prompt button. In the 'init' function at [2], you can select the default button by doing something like 'this.ui["button" + (args.defaultButtonNum || 0)]' and then apply our CSS class for default buttons to it
  - I'm not sure what would be the easiest way to make the highlight color of edit boxes in prompts orange, but I imagine that it will involve metro-specific CSS. So far, metro-specific prompt CSS has gone in [5]

Hope this helps! Let me know if there are any other questions I can help answer. Thanks again for looking at this

[1] https://mxr.mozilla.org/mozilla-central/source/toolkit/components/prompts/content/tabprompts.xml?rev=80e4ab0d24bc#217
[2] https://mxr.mozilla.org/mozilla-central/source/toolkit/components/prompts/content/tabprompts.xml?rev=80e4ab0d24bc#139
[3] https://mxr.mozilla.org/mozilla-central/source/toolkit/components/prompts/content/tabprompts.xml?rev=80e4ab0d24bc#25
[4] https://mxr.mozilla.org/mozilla-central/source/browser/metro/theme/platform.css?rev=212facdbf920#79
[5] https://mxr.mozilla.org/mozilla-central/source/browser/metro/theme/platform.css?rev=212facdbf920#550
Posted patch 801187.patch (obsolete) — Splinter Review
WIP

Had to disable resize logic in tabprompts. Also added options to show info tile and align info container to the left. Everything else was done in CSS.

The only thing I wasn't able to do yet is the two line prompt. I won't worry about it now (who stil uses prompt anyway? :) )
Posted image Alert.png
Alert screenshot
Posted image Prompt.png
Prompt screenshot
Posted image Auth.png
Authentication screenshot
Posted image PromptSnapped.png
Snapped prompt screenshot
Posted patch 801187.patch (obsolete) — Splinter Review
Fix.

I had to disable the resize code in tabprompts.xml for metro. I think we can get rid of this logic by using vh/vw or percentages. I can open a new bug if that's reasonable.
Attachment #799038 - Flags: review?(mbrubeck)
No new string needed.
Whiteboard: [preview] [l10n] feature=change c=Content_features u=metro_firefox_user p=3 → [preview] feature=change c=Content_features u=metro_firefox_user p=3
Comment on attachment 799038 [details] [diff] [review]
801187.patch

Review of attachment 799038 [details] [diff] [review]:
-----------------------------------------------------------------

r=mbrubeck with a quibble about selectors.

You'll need a toolkit peer to review the tabprompts.xml changes.

::: browser/metro/theme/platform.css
@@ +572,4 @@
>    border: none;
>  }
>  
> +.buttonContainer button {

We might want to use ".buttonContainer > button" to reduce possible perf impact.  Or add classes to the buttons in tabprompts.xml.

@@ +576,5 @@
> +  min-width: @touch_action_minwidth@;
> +  margin: 5px 0 5px @metro_spacing_xnormal@;
> +}
> +
> +.topContainer textbox {

Similarly, these should either be like ".topContainer > rows > row > label" or we should make it possible to use class selectors.

I haven't worried too much about selector efficiency in Metro because our chrome is so small, but cases like these could be pretty bad - they will require searching all the way up the ancestry chain of every button, textbox, label, and checkbox anywhere in our UI.
Attachment #799038 - Flags: review?(mbrubeck) → review+
Posted patch Patch v2 (obsolete) — Splinter Review
Updated patch with mbrubeck's comments. r? Dolske as he has reviewed the last few meaningful changes to tabprompts.xml.
Attachment #799038 - Attachment is obsolete: true
Attachment #799664 - Flags: review?(dolske)
Comment on attachment 799664 [details] [diff] [review]
Patch v2

Review of attachment 799664 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/components/prompts/content/tabprompts.xml
@@ +173,4 @@
>                    this.ui.infoTitle.removeAttribute("hidden");
>  
> +                if (args.alignLeft)
> +                  this.ui.infoContainer.setAttribute("align", "left");

Presumably you can override the defaults set in the XBL with CSS, using -moz-box-align? It and the attribute should do the same thing.

[In theory I suppose all of the (existing) such attributes should be in theme CSS, I guess we just didn't bother because it was a cut'n'paste from the modal window code?]

@@ +181,5 @@
> +                // TODO: Better yet, remove resize logic. Use min/max width and vw instead?
> +                if (!this.args.skipResize) {
> +                  window.addEventListener("resize", this, false);
> +                  this.onResize();
> +                }

Why this change?

I assume Metro, sorta always being always full-screen, doesn't actually ever resize, but the listener should be harmless in that case.

onResize() is called initially to set things up for the current state; it would have been nice to do this purely in CSS but it wasn't working out (see bug history if you're curious).

Seems like this should be left as-is, including the initial call to onResize(). Which would also remove the need for a skipResize arg.
Attachment #799664 - Flags: review?(dolske) → review-
> I assume Metro, sorta always being always full-screen, doesn't actually ever resize

Resizing is pretty common, you can have 2 immersive applications open sharing the screen.
(In reply to Justin Dolske [:Dolske] from comment #24)

Thanks for the review!

> Review of attachment 799664 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: toolkit/components/prompts/content/tabprompts.xml
> @@ +173,4 @@
> >                    this.ui.infoTitle.removeAttribute("hidden");
> >  
> > +                if (args.alignLeft)
> > +                  this.ui.infoContainer.setAttribute("align", "left");
> 
> Presumably you can override the defaults set in the XBL with CSS, using
> -moz-box-align? It and the attribute should do the same thing.
> 
> [In theory I suppose all of the (existing) such attributes should be in
> theme CSS, I guess we just didn't bother because it was a cut'n'paste from
> the modal window code?]
> 

I tried adding -moz-box-align: start !important; but it didn't work, the attribute takes precedence. I will remove the attribute from the element, move it to tabpromps.css and overwrite it for metro instead of the option.

> @@ +181,5 @@
> > +                // TODO: Better yet, remove resize logic. Use min/max width and vw instead?
> > +                if (!this.args.skipResize) {
> > +                  window.addEventListener("resize", this, false);
> > +                  this.onResize();
> > +                }
> 
> Why this change?
> 
> I assume Metro, sorta always being always full-screen, doesn't actually ever
> resize, but the listener should be harmless in that case.
> 
> onResize() is called initially to set things up for the current state; it
> would have been nice to do this purely in CSS but it wasn't working out (see
> bug history if you're curious).
> 
> Seems like this should be left as-is, including the initial call to
> onResize(). Which would also remove the need for a skipResize arg.

As bbondy mentioned, the resize listener gets called when you switch to snapped/portrait/filled views. On windows 8.1 you can resize the window when you have multiple immersive apps running side by side.

The resize logic is forcing the size of the dialog to be at most 60% of the window, we wanted it larger (see screenshots). I tried overwriting in CSS everything that was set on resize, but it was very hacky and messy, plus setting width and overflow programmatically had the effect of making the infoContainer always show the scrollbars or be cropped even with only one line of text - unless I removed all padding. After fighting for a while I decided to add this arg to disable resize.

I will try to replace the resizing logic with CSS only by using vw/vh. The tab modal resizing discussion I found was bug 613749, which happened before the landing of vw/vh length unit last year (bug 503720).
Posted patch Resize TabPrompt (obsolete) — Splinter Review
My attempt on using CSS to resize tab modal prompt. I wasn't able to get the infoContainer growing vertically when adding more text to infobody, so I had to add this and keep the resize logic :(. There might be some XUL trickery to fix this.

I was using Dolske's site to test prompts [1] and they were all working fine except "YourMom" (respectfully, of course :)) which was showing scrollbars. Adding an extra 17px to compensate for the scrollbar height fixed it. I wasn't able to figure out a way to get the scrollbar height or use getScrollbarSize()[2].

Dolske, is this something you think is worth persuing? Do you know if australis will change prompts?

[1] http://dolske.net/mozilla/tests/prompt/sizes.html 
[2] https://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIDOMWindowUtils.idl#659
Attachment #800398 - Flags: feedback?(dolske)
Posted patch Resize TabPrompt v2 (obsolete) — Splinter Review
Other proposal, this time setting overflow: auto when needed. This patch removes the need to know scrollbar height and "YourMom" is fine.

Try run:
https://tbpl.mozilla.org/?tree=Try&rev=470867422f01
Attachment #800398 - Attachment is obsolete: true
Attachment #800398 - Flags: feedback?(dolske)
Attachment #801065 - Flags: review?(dolske)
Try results were green with 3 known failures.
Blocks: metrov1it15
No longer blocks: metrov1it14
Depends on: 877225
Comment on attachment 801065 [details] [diff] [review]
Resize TabPrompt v2

Hmmm, bad news is that vh/vw is based on the whole window size, so if you have a tall prompt and the dev tools open for instance they get cropped :/
Attachment #801065 - Flags: review?(dolske)
Posted patch Toolkit Change (obsolete) — Splinter Review
I couldn't work around the resize, so going back to having an option and disabling it for metro only.

Using -moz-box-align instead of an option to set the attribute.
Attachment #801065 - Attachment is obsolete: true
Attachment #810292 - Flags: review?(dolske)
Posted patch Metro changes (obsolete) — Splinter Review
Now handling "super tall" and "4k wide" dialogs from [1].

Will set r? once toolkit part is finalized.

[1] - http://dolske.net/mozilla/tests/prompt/sizes.html
Attachment #798326 - Attachment is obsolete: true
Attachment #799664 - Attachment is obsolete: true
Blocks: metrov1it16
No longer blocks: MetroPreviewRelease, metrov1it15
Summary: [MP] Change - Theme tab-modal prompts to look good in Metro → Change - Theme tab-modal prompts to look good in Metro
Whiteboard: [preview] feature=change c=Content_features u=metro_firefox_user p=3 → feature=change c=Content_features u=metro_firefox_user p=3
Whiteboard: feature=change c=Content_features u=metro_firefox_user p=3 → [preview-triage] feature=change c=Content_features u=metro_firefox_user p=3
Blocks: metrov1it17
No longer blocks: metrov1it16
Whiteboard: [preview-triage] feature=change c=Content_features u=metro_firefox_user p=3 → [triage] feature=change c=Content_features u=metro_firefox_user p=3
No longer blocks: 892575
Whiteboard: [triage] feature=change c=Content_features u=metro_firefox_user p=3 → feature=change c=Content_features u=metro_firefox_user p=3
Ping. Feel free to forward to another toolkit peer.
Flags: needinfo?(dolske)
Whiteboard: feature=change c=Content_features u=metro_firefox_user p=3 → [block28] feature=change c=Content_features u=metro_firefox_user p=3
Blocks: metrov1it18
No longer blocks: metrov1it17
Another solution using a new tab modal prompt binding.
Attachment #810292 - Attachment is obsolete: true
Attachment #810293 - Attachment is obsolete: true
Attachment #810292 - Flags: review?(dolske)
Attachment #828342 - Flags: review?(mbrubeck)
Flags: needinfo?(dolske)
Blocks: metrov1it19
No longer blocks: metrov1it18
Comment on attachment 828342 [details] [diff] [review]
New tab modal prompt binding

Review of attachment 828342 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/metro/theme/platform.css
@@ +600,5 @@
> +  margin-left: 0;
> +}
> +
> +.topContainer > rows > row > checkbox {
> +  margin-left: 0;

Should probably use -moz-margin-start and -moz-padding-start here.
Attachment #828342 - Flags: review?(mbrubeck) → review+
https://hg.mozilla.org/mozilla-central/rev/ba2e9f9f2991
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 28
For QA: Look at the mockups at [1] and check for major look and feel discrepancies in the implementation. A good site to test the implementation is [2]. For authentication you can go to [3]. Note that it'll not be pixel perfect, but should resize fine in different snapped modes. Bug 940211 has been files about the look on short dialogs.

[1] - https://bugzilla.mozilla.org/attachment.cgi?id=790558
[2] - http://dolske.net/mozilla/tests/prompt/sizes.html
[3] - http://intranet.mozilla.org/
Posted file 3 screenshots.zip
Thanks Rodrigo for the guidelines.

I've tested this on Win 8 32-bit and 64-bit, with latest Nightly (build ID: 20131128030201) and it looks good.

Here are my questions (please see the attached .zip for details):

1) for the prompt dialog: the height of the text field doesn't double the height of the leading of the content, as mentioned in the .pdf file;  is this available only for devices?

2) for the authentication dialog: while in Snapped View, it doesn't look the same as in the .pdf file (the text fields are shorter, but they seem to be ok like this, considering we are in Snapped View)

3)regarding "YourMom" button: it shows a small layout issue while in Snapped View (for prompt, confirm, alert); more details in the corresponding screenshot

Does this also need verification on Win 8.1 ?
(In reply to Manuela Muntean [:Manuela] [QA] from comment #39)
> I've tested this on Win 8 32-bit and 64-bit, with latest Nightly (build ID:
> 20131128030201) and it looks good.
> 

Thanks for the thorough testing.

> Here are my questions (please see the attached .zip for details):
> 
> 1) for the prompt dialog: the height of the text field doesn't double the
> height of the leading of the content, as mentioned in the .pdf file;  is
> this available only for devices?
> 

Nice catch! I didn't add the two line text input because I didn't think it was too bad with the extra padding. Who uses prompt anyway :P  Yuan, do you think it's necessary?

> 2) for the authentication dialog: while in Snapped View, it doesn't look the
> same as in the .pdf file (the text fields are shorter, but they seem to be
> ok like this, considering we are in Snapped View)
> 

It should be using more of that extra space to the right, we need a bug for that.

> 3)regarding "YourMom" button: it shows a small layout issue while in Snapped
> View (for prompt, confirm, alert); more details in the corresponding
> screenshot
> 

Good eye! This looks like a bug on the way we render overlay scrollbars in metro. We need a separate bug for this too.

> Does this also need verification on Win 8.1 ?

It would be nice since in 8.1 we have different possible sizes for the window that could uncover some more layout issues.
Flags: needinfo?(ywang)
(In reply to Rodrigo Silveira [:rsilveira] from comment #40)
> (In reply to Manuela Muntean [:Manuela] [QA] from comment #39)
> > I've tested this on Win 8 32-bit and 64-bit, with latest Nightly (build ID:
> > 20131128030201) and it looks good.
> > 
> 
> Thanks for the thorough testing.
> 
> > Here are my questions (please see the attached .zip for details):
> > 
> > 1) for the prompt dialog: the height of the text field doesn't double the
> > height of the leading of the content, as mentioned in the .pdf file;  is
> > this available only for devices?
> > 
> 
> Nice catch! I didn't add the two line text input because I didn't think it
> was too bad with the extra padding. Who uses prompt anyway :P  Yuan, do you
> think it's necessary?

I would suggest to tweak it if it's a simple fix. Doubled size field also is more touch-friendly.


> 
> > 2) for the authentication dialog: while in Snapped View, it doesn't look the
> > same as in the .pdf file (the text fields are shorter, but they seem to be
> > ok like this, considering we are in Snapped View)
> > 
> 
> It should be using more of that extra space to the right, we need a bug for
> that.
> 
> > 3)regarding "YourMom" button: it shows a small layout issue while in Snapped
> > View (for prompt, confirm, alert); more details in the corresponding
> > screenshot
> > 
> 
> Good eye! This looks like a bug on the way we render overlay scrollbars in
> metro. We need a separate bug for this too.
> 
> > Does this also need verification on Win 8.1 ?
> 
> It would be nice since in 8.1 we have different possible sizes for the
> window that could uncover some more layout issues.
Flags: needinfo?(ywang)
> > 2) for the authentication dialog: while in Snapped View, it doesn't look the
> > same as in the .pdf file (the text fields are shorter, but they seem to be
> > ok like this, considering we are in Snapped View)
> > 
> 
> It should be using more of that extra space to the right, we need a bug for
> that.

I've logged bug 945249 and CC'ed you.

> > 3)regarding "YourMom" button: it shows a small layout issue while in Snapped
> > View (for prompt, confirm, alert); more details in the corresponding
> > screenshot
> > 
> 
> Good eye! This looks like a bug on the way we render overlay scrollbars in
> metro. We need a separate bug for this too.

I've logged bug 945252 and CC'ed you.

> It would be nice since in 8.1 we have different possible sizes for the
> window that could uncover some more layout issues.

I will test on 8.1 too, as soon as possible.
Posted file 8.1 64-bit.zip
I've also tested this on Win 8.1 Pro 64-bit, with latest Nightly 2013-12-02. Please see below my results:

1) regarding bug 945249: please see the "authentication_Snapped View.png" attached here; is this expected on Win 8.1 or is it bug 945249? 

2) bug 945252 is reproducible here too

3) please see "Snapped View_all 3.png" attached here, for how all 3 dialogs (alert, confirm and prompt) look like in Snapped View; is this expected?
Flags: needinfo?(rsilveira)
(In reply to Manuela Muntean [:Manuela] [QA] from comment #43)
> I've also tested this on Win 8.1 Pro 64-bit, with latest Nightly 2013-12-02.
> Please see below my results:
> 
> 1) regarding bug 945249: please see the "authentication_Snapped View.png"
> attached here; is this expected on Win 8.1 or is it bug 945249? 
> 
> 2) bug 945252 is reproducible here too
> 
> 3) please see "Snapped View_all 3.png" attached here, for how all 3 dialogs
> (alert, confirm and prompt) look like in Snapped View; is this expected?

The dialogs on 8.1 look fine, the other bugs will cover the remaining details. Thanks!
Flags: needinfo?(rsilveira)
Status: RESOLVED → VERIFIED
Also verified with latest Holly build from 2013-12-04 on Win 8.1 Pro 64-bit.
Verified as fixed with latest Aurora on Win 8 64-bit and Win 8.1 64-bit.
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.