Closed Bug 1181987 Opened 9 years ago Closed 9 years ago

Display a tile when the link clicker is waiting alone in a conversation

Categories

(Hello (Loop) :: Client, defect, P1)

defect

Tracking

(firefox42 verified)

VERIFIED FIXED
mozilla42
Iteration:
42.3 - Aug 10
Tracking Status
firefox42 --- verified

People

(Reporter: RT, Assigned: Mardak)

References

Details

(Whiteboard: [tiles])

User Story

As a product manager I want to test advertising as a monetisation solution for Firefox Hello on the link clicker site.

Acceptance criteria:
- As a link clicker on the standalone client UI, after joining the conversation, if I am alone in the conversation a tile gets displayed until the link generator joins
- The tile is displayed to any supported browser type and uses a standard tile size
- Tiles are localized and served to the user based on locale/geo information apparent from the user’s HTTP request (Mozilla tiles are already available and localized to serve in 114 countries and 7 locales (available to be localized in 50/60 locales and ready for the full 81))
- As the link generator joins, the tile stops being displayed and the conversation can happen
- A Google analytics event will be sent on ad click to track per session clicks on ads

Tile details (just context for this implementation):
- The ad served will be a directory tile, only house ads to start, so type=affiliate (Mozilla tiles).
- No suggested Tiles
- Tile rotation frequency: TBD

Attachments

(5 files, 7 obsolete files)

      No description provided.
Group: mozilla-employee-confidential
User Story: (updated)
Depends on: 1181368
RT will move to a Rank 16 once Content Services team resolves bug 1181368
Rank: 21
Flags: firefox-backlog+
Priority: -- → P2
Whiteboard: [tiles][blocked]
Depends on: 1182449
Depends on: 1183835
Ed, per the discussions earlier this week it sounded like things are ready on your side for us to at least test on our staging environment.
Can you please provide the details for tiles integration on this bug?
Flags: needinfo?(edilee)
Attached image wip screenshot (obsolete) —
RT, do you have a link to a visual spec? I have a shrunken screenshot that seems to indicate there's a question mark bubble above the tile.
Flags: needinfo?(edilee)
Attached image tiles UX aha.png
(In reply to Ed Lee :Mardak from comment #3)
> Created attachment 8635330 [details]
> wip screenshot
> 
> RT, do you have a link to a visual spec? I have a shrunken screenshot that
> seems to indicate there's a question mark bubble above the tile.

Now attached.
The question mark bubble you mention is the SUMO link?
Attached patch wip (obsolete) — Splinter Review
Initial patch that seems to work
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attached image wip fr screenshot (obsolete) —
From a fr build of Firefox 39
(In reply to Romain Testard [:RT] from comment #5)
> The question mark bubble you mention is the SUMO link?
Do you have the url for that link?
Oh, that's the same url for the guest/general support:

server.js:    "loop.config.guestSupportUrl = 'https://support.mozilla.org/kb/respond-firefox-hello-invitation-guest-mode';",
server.js:    "loop.config.generalSupportUrl = 'https://support.mozilla.org/kb/respond-firefox-hello-invitation-guest-mode';",


To be clear, I'm referring to the small bubble just above the tile to the right of "Want something to read while you wait?"

There'll be two question bubbles that link to the same page?
OK I misunderstood then - apologies.
Sevaan, your UX shows a question mark just above the tile to the right of "Want something to read while you wait?"
What is the purpose of it? Should we ignore it?
Flags: needinfo?(sfranks)
I talked to Sevaan separately.
We want that link and it has to point to a page explaining to users what tiles in Firefox Hello are.
This is a similar approach to https://support.mozilla.org/en-US/kb/how-do-tiles-work-firefox
Joni, is this something you could help us with regarding support page content? (I can take you through some of the details in a call if that helps)
Flags: needinfo?(jsavage)
Flags: needinfo?(sfranks)
Comment on attachment 8635344 [details] [diff] [review]
wip

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

Thanks for your work on this so far, Ed. The demos are definitely looking good.

Just a couple of fly-by comments that should help get this nearer to landing quicker.

::: browser/components/loop/content/shared/css/conversation.css
@@ +1347,5 @@
>    position: absolute;
>    /* `top` is chosen to vertically position the area near the center
>       of the media element. */
> +  top: 50%;
> +  transform: translateY(-75%);

I haven't tried this, but I definitely like the idea (it'll probably fix some of our other issues as well).

@@ +1352,4 @@
>    left: 25%;
>    z-index: 1000;
>    /* `width` here is specified by the design spec. */
> +  width: 290px;

We might want to check that narrow displays are fine with this size - I think our current screen css widths might have trouble with this.

::: browser/components/loop/standalone/content/js/standaloneRoomViews.jsx
@@ +113,5 @@
>                <p className="empty-room-message">
>                  {mozL10n.get("rooms_only_occupant_label")}
>                </p>
> +              <p>{mozL10n.get("rooms_read_wait")}</p>
> +              <iframe src="https://tiles.cdn.mozilla.net/iframe.html"

It'd be good if we could make the url configurable, see here for an example:

http://mxr.mozilla.org/mozilla-central/search?string=legalWebsiteUrl&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central

@@ +117,5 @@
> +              <iframe src="https://tiles.cdn.mozilla.net/iframe.html"
> +                      style={{border: 0,
> +                              borderRadius: "5px",
> +                              height: "204px",
> +                              width: "290px"}}/>

We haven't generally been using in-line styles, although I appreciate you might have just been putting it here for ease of hacking. I think it'd be best to move this to a class defined in webapp.css
Sure, Romain. Here's the placeholder: https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/hello-tiles

When do we need the article by?

I'll draft the article in this Google Doc and let you know when it's ready for review: https://docs.google.com/a/mozilla.com/document/d/1SBzpeLTudCVwanMsEm7ZBy62BeyW90ElWCwbsAqNOMU/edit?usp=sharing
Flags: needinfo?(jsavage)
(In reply to Ed Lee :Mardak from comment #15)
> (In reply to Joni Savage from comment #14)
> > https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/hello-tiles
> Is this supposed to be used for non-Firefox browsers as well?
Yes, currently Chrome, Firefox and Opera users would be exposed to that page.
(In reply to Joni Savage from comment #14)
> Sure, Romain. Here's the placeholder:
> https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/hello-tiles
> 
> When do we need the article by?

Our target launch date is August 23rd

> 
> I'll draft the article in this Google Doc and let you know when it's ready
> for review:
> https://docs.google.com/a/mozilla.com/document/d/
> 1SBzpeLTudCVwanMsEm7ZBy62BeyW90ElWCwbsAqNOMU/edit?usp=sharing

Thanks, I'll review and add comments
(In reply to Ed Lee :Mardak from comment #15) 
> Could we just use https://support.mozilla.org/%LOCALE%/tiles-firefox-hello ?

Sorry, I forgot that this was for other browsers too. Yes, let's use https://support.mozilla.org/%LOCALE%/tiles-firefox-hello instead.
(In reply to Joni Savage from comment #18)
> (In reply to Ed Lee :Mardak from comment #15) 
> > Could we just use https://support.mozilla.org/%LOCALE%/tiles-firefox-hello ?
> 
> Sorry, I forgot that this was for other browsers too. Yes, let's use
> https://support.mozilla.org/%LOCALE%/tiles-firefox-hello instead.

Can we avoid the locale, and just let sumo auto-detect that (as we do elsewhere)?
(In reply to Mark Banner (:standard8) from comment #19)
> Can we avoid the locale, and just let sumo auto-detect that (as we do
> elsewhere)?

Yes, that will work.
Attached patch v1 (obsolete) — Splinter Review
(In reply to Mark Banner (:standard8) from comment #13)
> ::: browser/components/loop/content/shared/css/conversation.css
> @@ +1352,4 @@
> >    left: 25%;
> >    z-index: 1000;
> >    /* `width` here is specified by the design spec. */
> > +  width: 290px;
> We might want to check that narrow displays are fine with this size - I
> think our current screen css widths might have trouble with this.
It was partially overlapping with the right chat, so I updated the left to calculate the centering.

> ::: browser/components/loop/standalone/content/js/standaloneRoomViews.jsx
> @@ +113,5 @@
> > +              <iframe src="https://tiles.cdn.mozilla.net/iframe.html"
> It'd be good if we could make the url configurable
Added 2 urls to standalone/server.js

> @@ +117,5 @@
> > +              <iframe src="https://tiles.cdn.mozilla.net/iframe.html"
> > +                      style={{border: 0,
> > +                              borderRadius: "5px",
> > +                              height: "204px",
> > +                              width: "290px"}}/>
> We haven't generally been using in-line styles
Moved to webapp.css although not entirely sure where to put the styles. Maybe it should have its own /* section */ ?
Attachment #8635344 - Attachment is obsolete: true
Attachment #8639187 - Flags: review?(dmose)
Ed, per e-mail discussion we want a default non localized tile (probably just showing a Firefox logo) implemented for all non supported locales.

Per your comment "the tile-server/onyx doesn't currently support catch-all locales, but we can implement something in the iframe to fall back to a default "Firefox" or "Mozilla" tile with the appropriate reporting. (I'm thinking I can upload a tile for STAR/zu because I'm pretty sure
the "zu" locale is unused.)"

That sounds like a good idea, I am following that discussion up here since it feels there will be a client dependency - can you please confirm if a client code update is necessary to support it?
Flags: needinfo?(edilee)
Rank: 21
Priority: P2 → P1
Whiteboard: [tiles][blocked] → [tiles]
Rank: 19
Comment on attachment 8639187 [details] [diff] [review]
v1

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

This is looking good; thanks so much!

A few general thoughts:

* Trying to bring up the context menu while hovering over the tile brings up the popup blocker yellow bar in Nightly
* Please push both the text and the ? above the tile to the edges of the tile, a la the mockup

If we're lucky, pushing this down into the MediaLayoutView to reduce fragility will pan out, but if that gets complicated (which I think is moderately likely, thus the timeboxing recommendation), the way this patch is structured looks fine, and we'll go forward with that!

::: browser/components/loop/content/shared/css/conversation.css
@@ +1312,5 @@
>    /* `top` is chosen to vertically position the area near the center
>       of the media element. */
> +  top: 50%;
> +  transform: translateY(-75%);
> +  /* Center this to the full width minus 200px right-side chat and own width */

* make the "right-side chat" comment a bit clearer

@@ +1313,5 @@
>       of the media element. */
> +  top: 50%;
> +  transform: translateY(-75%);
> +  /* Center this to the full width minus 200px right-side chat and own width */
> +  left: calc((100% - 200px - 290px) / 2);

Add as a comment where 290px comes from.

::: browser/components/loop/standalone/content/css/webapp.css
@@ +63,5 @@
> +.standalone .tiles-iframe {
> +  border: 0;
> +  border-radius: 5px;
> +  height: 204px;
> +  width: 290px;

COmments on where these values come from, please.

::: browser/components/loop/standalone/content/l10n/en-US/loop.properties
@@ +99,5 @@
>  rooms_list_deleteConfirmation_label=Are you sure?
>  rooms_new_room_button_label=Start a conversation
>  rooms_only_occupant_label=You're the first one here.
>  rooms_panel_title=Choose a conversation or start a new one
> +rooms_read_wait=Want something to read while you wait?

A slightly more descriptive string for localizers would be nice (maybe rooms_read_while_waiting_offer)?  As well as a localizer content that explains in more details what exactly this is.
Attachment #8639187 - Flags: review?(dmose) → review-
Comment on attachment 8635338 [details]
tiles UX aha.png

Vicky, since we're doing the visual UX refresh now, it would be very helpful to have a mock of how this should look style, as it may make sense to try and do that work as part of this bug...
Flags: needinfo?(vpg)
er "how this should look in that style"
Mardak: one other thing that's missing from this file is a simple unit test or two to make sure that we're actually rendering the iframe and maybe setting the URL on it correctly.
Vicky, also how should this look for small screens (less than 640px wide)?
Flags: needinfo?(edilee)
Depends on: 1188604
Attached patch v2 (obsolete) — Splinter Review
(In reply to Dan Mosedale (:dmose) - needinfo? me for response from comment #23)
> * Trying to bring up the context menu while hovering over the tile brings up
> the popup blocker yellow bar in Nightly
Filed bug 1188604

> * Please push both the text and the ? above the tile to the edges of the
> tile, a la the mockup
Done with flex justify space-between.

> If we're lucky, pushing this down into the MediaLayoutView to reduce
> fragility will pan out
I did this by putting children of MediaLayoutView into the div containing remote stream.

> ::: browser/components/loop/content/shared/css/conversation.css
> @@ +1312,5 @@
> >    /* `top` is chosen to vertically position the area near the center
> >       of the media element. */
> > +  top: 50%;
> > +  transform: translateY(-75%);
> > +  /* Center this to the full width minus 200px right-side chat and own width */
> * make the "right-side chat" comment a bit clearer
> @@ +1313,5 @@
> >       of the media element. */
> > +  top: 50%;
> > +  transform: translateY(-75%);
> > +  /* Center this to the full width minus 200px right-side chat and own width */
> > +  left: calc((100% - 200px - 290px) / 2);
> Add as a comment where 290px comes from.
These are not needed anymore with the MediaLayoutView change.

> ::: browser/components/loop/standalone/content/css/webapp.css
> @@ +63,5 @@
> > +.standalone .tiles-iframe {
> > +  border: 0;
> > +  border-radius: 5px;
> > +  height: 204px;
> > +  width: 290px;
> COmments on where these values come from, please.
Done.

> ::: browser/components/loop/standalone/content/l10n/en-US/loop.properties
> @@ +99,5 @@
> > +rooms_read_wait=Want something to read while you wait?
> A slightly more descriptive string for localizers would be nice (maybe
> rooms_read_while_waiting_offer)?  As well as a localizer content that
> explains in more details what exactly this is.
Done.

> Mardak: one other thing that's missing from this file is a simple unit test
> or two to make sure that we're actually rendering the iframe and maybe
> setting the URL on it correctly.
Done.
Attachment #8639187 - Attachment is obsolete: true
Attachment #8640114 - Flags: review?(dmose)
Attached image v2 screenshot (large)
Attachment #8635330 - Attachment is obsolete: true
Attachment #8635346 - Attachment is obsolete: true
Attached image v2 screenshot (small)
Comment on attachment 8640114 [details] [diff] [review]
v2

>+++ b/browser/components/loop/standalone/content/js/standaloneRoomViews.jsx
>+              <iframe className="room-waiting-tile" src={loop.config.tilesIframeUrl}/>
Saw a nit from :mikedeboer that there's a space before "/>"
Depends on: 1188946
Attached patch v2.1 (obsolete) — Splinter Review
I was rebasing the patch and it conflicted with bug 1180179 attachment 8638505 [details] [diff] [review]:

Part 4. Use the shared media layout component in Loop's room views.

>@@ -1050,16 +1051,17 @@ loop.shared.views = (function(_, mozL10n) {
>             <div className={remoteStreamClasses}>
>               <MediaView displayAvatar={!this.props.renderRemoteVideo}
>                 isLoading={this.props.isRemoteLoading}
>                 mediaType="remote"
>                 posterUrl={this.props.remotePosterUrl}
>                 srcVideoObject={this.props.remoteSrcVideoObject} />
>               { this.state.localMediaAboslutelyPositioned ?
>                 this.renderLocalVideo() : null }
>+              { this.props.children }
>             </div>
>             <div className={screenShareStreamClasses}>
>               <MediaView displayAvatar={false}
>                 isLoading={this.props.isScreenShareLoading}
>                 mediaType="screen-share"
>                 posterUrl={this.props.screenSharePosterUrl}
>                 srcVideoObject={this.props.screenShareVideoObject} />
>             </div>

This looks like the same change I made except placed after the MediaView instead of before, but that shouldn't have much difference.

mikedeboer, just making sure this change from bug 1180179 was also to allow children to be appropriately positioned as static content in the remote space?
Attachment #8640114 - Attachment is obsolete: true
Attachment #8640114 - Flags: review?(dmose)
Attachment #8640917 - Flags: review?(dmose)
Attachment #8640917 - Flags: feedback?(mdeboer)
Comment on attachment 8640917 [details] [diff] [review]
v2.1

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

::: browser/components/loop/standalone/content/js/standaloneRoomViews.jsx
@@ +488,5 @@
>              screenShareVideoObject={this.state.screenShareVideoObject}
>              showContextRoomName={true}
> +            useDesktopPaths={false}>
> +            <StandaloneRoomInfoArea activeRoomStore={this.props.activeRoomStore}
> +                                    dispatcher={this.props.dispatcher}

This'll work, just like you mentioned - it is correct.

Please align the attributes just like we do for other elements in this file (indent with 2 spaces only).
Attachment #8640917 - Flags: feedback?(mdeboer) → feedback+
Attached patch v2.2 (obsolete) — Splinter Review
Fixed attribute indentation for both <a> and <StandaloneRoomInfoArea>
Attachment #8640917 - Attachment is obsolete: true
Attachment #8640917 - Flags: review?(dmose)
Attachment #8641119 - Flags: review?(dmose)
Depends on: 1188547
Comment on attachment 8641119 [details] [diff] [review]
v2.2

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

This looks good. 

I'm uploading an updated version of this patch with the following changes:

* regenerated one of the .js files from the .jsx
* made it easier to inspect/debug using the ui-showcase by adding a rule to ui-showcase.css giving it a grey background.  Feel free to upgrade that by removing the rule, and tweaking the UI-showcase to load a PNG of an actual tile in that iframe (not required for landing, but would be nice).
* addressed the Makefile and const stuff mentioned below

So this will be ready to go once the 290px comment is addressed, and you've verified with run-all-browser-tests.sh that things are kosher before you land (note that you might have to comment out the code section to make it run).

::: browser/components/loop/standalone/content/css/webapp.css
@@ +61,5 @@
> +.standalone .room-waiting-area {
> +  display: flex;
> +  justify-content: space-between;
> +  margin: 3em auto 1em;
> +  width: 290px;

Does the 290px width really need to be repeated 3 different times in the CSS files, or can we make some of these things be sized automatically?  If the answer is that we really need all three, a comment next to this one as well would be good too.

::: browser/components/loop/standalone/server.js
@@ +46,5 @@
>      "loop.config.fxosApp.rooms = true;",
>      "loop.config.fxosApp.manifestUrl = 'http://fake-market.herokuapp.com/apps/packagedApp/manifest.webapp';",
>      "loop.config.roomsSupportUrl = 'https://support.mozilla.org/kb/group-conversations-firefox-hello-webrtc';",
> +    "loop.config.tilesIframeUrl = 'https://tiles.cdn.mozilla.net/iframe.html';",
> +    "loop.config.tilesSupportUrl = 'https://support.mozilla.org/tiles-firefox-hello';",

Because of general awfulness on our part that needs to be DRYed out, these things also need to be added to standlone/Makefile in the config target.

I think they _also_ have to be somehow communicated to ops.  Ask :Standard8 how to do that by setting a needinfo on him.

::: browser/components/loop/test/standalone/standaloneRoomViews_test.js
@@ +182,5 @@
>            });
>  
> +        it("should display a waiting room message and tile iframe on JOINED",
> +          function() {
> +            const DUMMY_TILE_URL = "http://tile/";

./browser/components/loop/run-all-loop-tests.sh from the top-level noticed that we can't have const here, because this code should be cross-browser, so please change to var.

https://github.com/mozilla/gecko-dev/blob/master/browser/components/loop/README.txt#L43 talks a bit about linting.  Chances are good that whatever editor/IDE you use has a plugin that supports eslint, which catches these sorts of things as-you-type, see http://eslint.org/docs/user-guide/integrations for details.
Attachment #8641119 - Flags: review?(dmose) → review+
Thanks very much for this nice de-fragilization!  A few other thoughts:

I think it makes sense to land this bug as is, and if Vicky does respond to the needinfo with a desire to do a visual refresh, spin that off into, so if you could do that and CC me, that would be great.

Standard8, what do we need to do to notify ops of these config changes again?

Finally, for faster review turnaround, feel free to ping me at any time in IRC and suggest working through it over video chat, as I can often make time for that sooner, because it's so much more efficient.
Flags: needinfo?(standard8)
The success criteria was asking for a Google analytics event to be sent to track clicks on tiles (will allow correlating other GA traffic (JOIN events) to tile clicks.
Just checking whether it has been implemented?
(In reply to Dan Mosedale (:dmose) - needinfo? me for response from comment #37)
> Thanks very much for this nice de-fragilization!  A few other thoughts:
> 
> I think it makes sense to land this bug as is, and if Vicky does respond to
> the needinfo with a desire to do a visual refresh, spin that off into, so if
> you could do that and CC me, that would be great.
> 
> Standard8, what do we need to do to notify ops of these config changes again?
> 
> Finally, for faster review turnaround, feel free to ping me at any time in
> IRC and suggest working through it over video chat, as I can often make time
> for that sooner, because it's so much more efficient.

Yes, I have seen this and it is in my top to-do things. I might have it for monday. Thanks.
Leaving NI
The config changes we'll get ops to update when we do the release.

Ed, if you can land this today, then we can get the ball rolling for localising the strings tomorrow.
Flags: needinfo?(standard8)
(In reply to Romain Testard [:RT] from comment #38)
> The success criteria was asking for a Google analytics event to be sent to
> track clicks on tiles (will allow correlating other GA traffic (JOIN events)
> to tile clicks.
This wasn't implemented in this patch. Splitting it off in bug 1191014 so that we can land the current patch with strings sooner.
Blocks: 1191014
Group: mozilla-employee-confidential
https://hg.mozilla.org/mozilla-central/rev/e0c790a2af42
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Iteration: --- → 42.3 - Aug 10
(In reply to Victoria Gerchinhoren [:vicky] from comment #39)
> (In reply to Dan Mosedale (:dmose) - needinfo? me for response from comment
> #37)
> > Thanks very much for this nice de-fragilization!  A few other thoughts:
> > 
> > I think it makes sense to land this bug as is, and if Vicky does respond to
> > the needinfo with a desire to do a visual refresh, spin that off into, so if
> > you could do that and CC me, that would be great.
> > 
> > Standard8, what do we need to do to notify ops of these config changes again?
> > 
> > Finally, for faster review turnaround, feel free to ping me at any time in
> > IRC and suggest working through it over video chat, as I can often make time
> > for that sooner, because it's so much more efficient.
> 
> Yes, I have seen this and it is in my top to-do things. I might have it for
> monday. Thanks.
> Leaving NI

This instance is already created in the updated Link clickers visual mockups file.
Flags: needinfo?(vpg)
Attached image tile visual refresh
(In reply to Victoria Gerchinhoren [:vicky] from comment #44)
> This instance is already created in the updated Link clickers visual mockups
> file.
Just making sure, you're referring to bug 1179163 comment 2 which links to https://www.dropbox.com/sh/46pyq5wwgnif6g8/AACEqjLwDw1be0oMYw-okHA9a?dl=0

and page 5 has:

https://www.dropbox.com/sh/46pyq5wwgnif6g8/AACEqjLwDw1be0oMYw-okHA9a?dl=0&preview=LC_Dktp_WIP.png

I've attached a screenshot of the relevant step of that flow.
Ed: that looks right to me.  Can you spin that off into another bug that blocks the conversation window visual refresh (bug 1179164) and has firefox-backlog+ set, along with, say, P2?

One thing that will complicate things a bit is that we're hoping to land most of the conversation window refresh as part of a single release, and it's not clear whether 43 is going to be that release.  We can chat more when you get in.
Blocks: 1193810
(In reply to Ed Lee :Mardak from comment #45)
> Created attachment 8646965 [details]
> tile visual refresh
> 
> (In reply to Victoria Gerchinhoren [:vicky] from comment #44)
> > This instance is already created in the updated Link clickers visual mockups
> > file.
> Just making sure, you're referring to bug 1179163 comment 2 which links to
> https://www.dropbox.com/sh/46pyq5wwgnif6g8/AACEqjLwDw1be0oMYw-okHA9a?dl=0
> 
> and page 5 has:
> 
> https://www.dropbox.com/sh/46pyq5wwgnif6g8/AACEqjLwDw1be0oMYw-
> okHA9a?dl=0&preview=LC_Dktp_WIP.png
> 
> I've attached a screenshot of the relevant step of that flow.

That's right. Thanks!
Blocks: 1195812
Flags: qe-verify+
I verified that using Firefox 42 beta 4, latest Chrome and latest Opera versions, the tile is displayed across platforms (Windows 7 64-bit, Windows 10 64-bit, Ubuntu 12.04 32-bit and Mac OS X 10.10.5).
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: