If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

WebQA Review of Social Sharing Widget

VERIFIED FIXED

Status

mozilla.org
Webdev
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: cmore, Assigned: mbrandt)

Tracking

Details

(Whiteboard: [qa+], URL)

(Reporter)

Description

6 years ago
We need to have a WebQA review of the social sharing widget that Owen build.

Working example:

http://people.mozilla.org/~ocoutts/collusion/

Code that you can implement on any site:

https://github.com/mozilla/SocialShare

Let me know who we can get assigned to do the QA review and it should not be a lot of work. We would like to have finished by the first week in May 2012.

Thanks
(Reporter)

Updated

6 years ago
Whiteboard: [qa+]
Assignee: nobody → mozwebqa
OS: Mac OS X → All
Hardware: x86 → All
Going to go over this today with Raymond, Zac, and Dave.

Can we preload these two images:

[05:07:21.189] GET http://people.mozilla.org/~ocoutts/collusion/socialshare/media/img/heart-hover.png [HTTP/1.1 200 OK 286ms]
[05:07:21.193] GET http://people.mozilla.org/~ocoutts/collusion/socialshare/media/img/caret-open.png [HTTP/1.1 200 OK 288ms]
http://screencast.com/t/nyxeoNE4 -- the way it's at least implemented on this test Mozilla.org page, it's causing the viewport to expand horizontally -- can we ensure it stays within the bounds of the host page, somehow?
(Reporter)

Comment 3

6 years ago
(In reply to Stephen Donner [:stephend] from comment #1)
> Can we preload these two images:
> 
> [05:07:21.189] GET
> http://people.mozilla.org/~ocoutts/collusion/socialshare/media/img/heart-
> hover.png [HTTP/1.1 200 OK 286ms]
> [05:07:21.193] GET
> http://people.mozilla.org/~ocoutts/collusion/socialshare/media/img/caret-
> open.png [HTTP/1.1 200 OK 288ms]

They are located within the repo at:

https://github.com/mozilla/SocialShare/tree/master/media/img
(Reporter)

Comment 4

6 years ago
(In reply to Stephen Donner [:stephend] from comment #2)
> http://screencast.com/t/nyxeoNE4 -- the way it's at least implemented on
> this test Mozilla.org page, it's causing the viewport to expand horizontally
> -- can we ensure it stays within the bounds of the host page, somehow?

The location of the social share will have to be designed into the page and the collusion page was just an example (not perfect) and it was probably too far to the right of the page. If it was designed so that the pop up window was below the "share this" it would have been fine, but instead of the design specified that it should be centered under the caret. Let me check with the designers if it would be fine to adjust the pop up window.
(In reply to Chris More [:cmore] from comment #4)
> (In reply to Stephen Donner [:stephend] from comment #2)
> > http://screencast.com/t/nyxeoNE4 -- the way it's at least implemented on
> > this test Mozilla.org page, it's causing the viewport to expand horizontally
> > -- can we ensure it stays within the bounds of the host page, somehow?
> 
> The location of the social share will have to be designed into the page

True, though in Stephen's screencast, you can see that the viewport unnecessarily expands (i.e., there's no actual content sticking out), so that's probably a CSS bug.
(Reporter)

Comment 6

6 years ago
Doh! Yeah, Wenzel just showed me what Stephen was trying to highlight. I wasn't look at the bottom of the page to see that the horizontal scroll bar showed up. Owen is looking into it now. Nice find.
By comment 1, I was trying to indicate that those two images are only loaded on hover, so they're missing until then.  (This is like the old days when you put images that need to show up on :hover, and you make an array of them, so they can be preloaded.)
(Reporter)

Comment 8

6 years ago
Bugs filed:

Page width:

https://bugzilla.mozilla.org/show_bug.cgi?id=747533

Preloader:

https://bugzilla.mozilla.org/show_bug.cgi?id=747532
You should be able to open/close the widget with the keyboard.
(Reporter)

Comment 10

6 years ago
(In reply to Icaaq (Isac) from comment #9)
> You should be able to open/close the widget with the keyboard.

Thanks. Bug 747963 filed.
(Reporter)

Comment 11

6 years ago
Stephend: bug 747533 is resolved. Thanks for noticing the problem.
If more than one widget is appended to a page, and different data-tweet-at values are used on these widgets. Then the first data-tweet-at-value is used on all widgets.


Test page: http://icaaq.com/sandbox/mozilla/SocialShare/multiple.html
(Reporter)

Comment 13

6 years ago
(In reply to Icaaq (Isac) from comment #12)
> If more than one widget is appended to a page, and different data-tweet-at
> values are used on these widgets. Then the first data-tweet-at-value is used
> on all widgets.
> 
> 
> Test page: http://icaaq.com/sandbox/mozilla/SocialShare/multiple.html

I think this out of scope for this library. Why? Because most social sharing pulls in open graph meta data and falls back to "best attempt" meta data and you cannot set multiple versions of the same meta tags in a page and expect them to behave differently. Multiple sharing library instances per page is probably already an edge case and having them pulls in different data is out of scope. As it stands now, when you manually share pages on social networks, it pulls in the first occurrence of the meta tags.
(In reply to Chris More [:cmore] from comment #13)
> (In reply to Icaaq (Isac) from comment #12)
> > If more than one widget is appended to a page, and different data-tweet-at
> > values are used on these widgets. Then the first data-tweet-at-value is used
> > on all widgets.
> > 
> > 
> > Test page: http://icaaq.com/sandbox/mozilla/SocialShare/multiple.html
> 
> I think this out of scope for this library. Why? Because most social sharing
> pulls in open graph meta data and falls back to "best attempt" meta data and
> you cannot set multiple versions of the same meta tags in a page and expect
> them to behave differently. Multiple sharing library instances per page is
> probably already an edge case and having them pulls in different data is out
> of scope. As it stands now, when you manually share pages on social
> networks, it pulls in the first occurrence of the meta tags.

Ok, I see your point. But the twitter widget itself does not read the open graph meta data, it uses the data-tweet-at attribute set on the initiating element

<div class="socialshare" data-type="bubbles" data-tweet-at="tallowen"></div>
(Reporter)

Comment 15

6 years ago
> Ok, I see your point. But the twitter widget itself does not read the open
> graph meta data, it uses the data-tweet-at attribute set on the initiating
> element
> 
> <div class="socialshare" data-type="bubbles" data-tweet-at="tallowen"></div>

Yes, we built that functionality in by creating the JavaScript to look for the open graph meta tags and if they exist, it will insert the appropriate data-* meta dags into the DOM thus allowing Twitter to use the same meta data as Facebook and G+. The prerequisite for using the library is appropriately setting the open graph meta tags and if they are not set, it falls back to "best guess".
(In reply to Chris More [:cmore] from comment #15)
> > Ok, I see your point. But the twitter widget itself does not read the open
> > graph meta data, it uses the data-tweet-at attribute set on the initiating
> > element
> > 
> > <div class="socialshare" data-type="bubbles" data-tweet-at="tallowen"></div>
> 
> Yes, we built that functionality in by creating the JavaScript to look for
> the open graph meta tags and if they exist, it will insert the appropriate
> data-* meta dags into the DOM thus allowing Twitter to use the same meta
> data as Facebook and G+. The prerequisite for using the library is
> appropriately setting the open graph meta tags and if they are not set, it
> falls back to "best guess".

ok, good thinking :)
(Reporter)

Comment 17

6 years ago
pmac: can you install the social sharing library on a static copy of any Mozilla themed page (locally hosted on people.mozilla.org or another dev area)? We need QA to verify it on another page.
(Reporter)

Comment 18

5 years ago
Matt: We are now QA ready! Can you set up a meeting with us next week so we can get up to speed on what needs to be tested?
Assignee: mozwebqa → mbrandt
(Assignee)

Comment 19

5 years ago
(In reply to Chris More [:cmore] from comment #18)
> Matt: We are now QA ready! Can you set up a meeting with us next week so we
> can get up to speed on what needs to be tested?

Yay! woot woot. Will do - see you next week in MV. The QA train is set to sail.
(Reporter)

Comment 20

5 years ago
Matt: Here is the URL that you should be testing the widget:

http://people.mozilla.org/~pmclanahan/collusion/

I would also recommend pulling the code in the repo and hosting it locally on another web-accessible location to test:

https://github.com/mozilla/SocialShare
(Assignee)

Comment 21

5 years ago
Choo-choo - many thanks cmore for the simple yet complete view of the landscape of what needs to be tested. QA will descend and begin verifying.
(Assignee)

Updated

5 years ago
Depends on: 766648
(Assignee)

Updated

5 years ago
Depends on: 766649
(Reporter)

Comment 22

5 years ago
Thanks, mbrandt for the QA review!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Comment 23

5 years ago
Thanks Chris!

Bumping to QA verified - 
* verified on desktop: Firefox RC and Firefox Beta, Chrome, Opera, Safari
* verified mobile iOS , Firefox for Android (RC & Beta), Android Browser, and Chrome for Android
* platforms: OSX, Win7, iPad, Android Tablet, Android Phone
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.