mozilla / socialapi-dev Goto Github PK

The chat window gets the "glass" theme on Windows but the title-bar can't be dragged, meaning there is no way for the user to reposition it.

For example, the Add-ons Manager page, and about:permissions.

In these cases we should probably hide the sidebar entirely.

If there are serviceWindows open, should the user be given a chance to confirm before deactivating the service, since this will terminate the windows (which could mean cutting off a chat)?

FYI: The following changes were made to this repository's wiki:

• defacing spam has been removed

• Restricting write access to contributors is strongly encouraged. Please make that change (documentation).

These were made as the result of a recent automated defacement of publically writeable wikis.

Rev 73ecfd1 enables history in the sidebar panel to work around a problem with one of our partners. Apparently, with history disabled, window.history.replaceState exists but throws an exception. Our partner is expecting that if it is disabled window.history or window.history.replaceState should be undefined. We should confirm that, confirm it is a bug in Firefox and re-disable once fixed.

We should determine when a window.open call is intended to create a "popup" window, and not insert the sidebar in this case. At a minimum, the absence of the "toolbar" feature should be used as a clue.

STR:

make sure your bookmarks bar has bookmarks all the way to the right
collapse the social sidebar

-> the social sidebar overlaps the bookmarks, as opposed to shoving the menu to the left.

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC001)

We could put shares/recommends into the Places database and make them available for AwesomeBar searches and other good stuff.

We have a location change watcher to ensure the sidebar never moves from the correct domain. If it detects such movement it does a goBack() call to take us back to the correct domain.

Consider a scenario where a page on the correct domain ends up doing a redirect to a page off the domain. When we do goBack() we wind up back at the page doing the redirect, so the process would repeat indefinitely.

A possible solution might be to always return to the "start" page for the service - although that would suffer the same problem in the (unlikely) case the main page does a redirect.

I think having the sidebar pop open on every new window will lead to annoyance. Let's default to minimized.

The servicewindow does not currently display the SSL badging; I suggest that we use the technique previously prototyped in OAuthorizer to place a permanent location badge and trigger point for a certificate-display popup.

Frameworker calls reportError instead of Cu.reportError when there's an error in evaluating the JS for the provider's worker.

Almost all of the widget code could be moved back to modules so they aren't referenced in the overlays <script> tags and thus don't pollute the window's global.

in frameworker.js, around line #201, we directly assign to the frame's contentWindow, like this:

    frame.contentWindow.onoffline = function() {
      if (sandbox.onoffline) sandbox.onoffline();
    };

This causes a crash in Nightly.

*** Compartment mismatch 0x1067d6000 vs. 0x114047000
Assertion failure: compartment mismatched, at /Users/anant/Code/alder/js/src/jscntxtinlines.h:156
Segmentation fault: 11

Nightly from the last day or 2 is having issues with our ArrayBuffer/Uint8Array dances. The problem manifests itself as errors:

2012-03-28T07:01:50.339Z [mqtt]: Malformed message
2012-03-28T07:01:50.343Z [mqtt]: ERROR parsing onmessage: TypeError: parsedCommand is undefined

digging deeper the problem is connection.parse is attempting to parse zero bytes. Digging deeper still - I changed the first few lines of connection.parse to read:

mqttlog("got a rawBuffer with size " + rawBuffer.byteLength);
var buf = new Uint8Array(rawBuffer);
mqttlog("resulting array has size " + buf.length);

and the output from this is:

2012-03-28T06:59:53.661Z [mqtt]: got a rawBuffer with size 4
2012-03-28T06:59:53.664Z [mqtt]: resulting array has size 0

So somehow we are getting a zero byte array from a 4 byte message buffer. A trivial test can't reproduce this.

sigh

If the user has multiple service providers active and deactivates the currently visible one, should the sidebar switch to the next one in the list, or be hidden? Will flag as UX issue.

When the sidebar is changed to a new service provider, the recommend button should repaint with the service provider's icon.

In sidebarWidget's reflow() method, we (a) look for an element with the ID of "header" then (b) set the height of that element to be the height of the toolbar we are anchored to. This has a number of problems:

• The ID of the header is hard-coded; it works for facebook but may not work for other providers.
• If the bookmark toolbar happens to be the bottom-most displayed toolbar, the height of this toolbar is too small for the facebook header - it gets truncated, and obviously so. Each of the toolbars has a different height! The same thing happens but is less obvious when one of the other toolbars is at the bottom.
• The content may adjust the height at any time, making the above pointless. Eg, we set the height, but as soon as the facebook content fully loads (ie, after the throbber goes away and our account into is displayed), it resets the height back to what it was. This means that when the bookmark toolbar is displayed, we set the height correctly, but a few seconds later it grows back to the original size. When we next reflow the sidebar we then adjust it back.

There is a comment in that code "// TODO XXX Need an API to inform the content page how big to make the header" but that doesn't quite capture all these subtle points.

When we use the MozAlerts service to display notifications, we get an icon, a title, and some text. If we let the service provider specify all three of those, we don't have a way to badge a notification with either Firefox or the service provider's name.

This can be good, in that it means the notification is all user-centric data (a face of someone I know, and a message I want to hear about them), but it could lead to confusion ("what service is showing me this?") and, in the worst case, abuse.

We should consider lightweight ways of "badging" the notification element to make this connection more clear, especially on desktop OSes where the notification elements are quite generic.

On Mac for certain; have to check elsewhere.

STR:

• Start Firefox with the addon enabled.
• Disable the addon
• Enable the addon
• Load about:social

The about:social page does not display.

The social browsing popup should allow the user to switch the displayed service for its window; this should refocus the sidebar to the selected service and refocus the webProgressListener for the sidebar's browser. It should also refresh the recommend icon.

provider.js keeps a reference to the worker object (and thus to the port) and the port is never closed. This isn't apparent in the facebook provider as that worker keeps references to all ports and closes them all in onterminate(), which also closes the client side of the port. We shouldn't rely on this as not all providers will need or want to keep references to all ports. AFAIK, this is the only "client port" not explicitly closed.

This one, for example: http://www.getpersonas.com/en-US/persona/16

(Per discussion with Mark) setting up an issue to track this: Without access to cookies in the worker, the chrome-jewels can only be updated when the sidebar is loaded, since the worker won't be able to determine whether the user is logged in/out.

The navigation watcher currently in sidebarWidget.js doesn't always detect and stop navigation events.

spec calls for, and it's implemented, that after a "user-recommend", the service may respond with a user-recommend-prompt-response so the icon and message change to reflect the action. However, while the recommend widget honors the second prompt response, it doesn't arrange to reset the prompt back to the default when URL changes (eg, tab switch, navigation, etc).

ie, if the server responds with a "you liked this!" after clicking, that new text would stay there forever!

There is currently no mechanism to refresh a sidebar or service window. This can cause problems when connectivity is spotty.

Let's implement a context menu popup, at least.

Either as a preference pane, or as about:social, we should have a place where the user can see all of the available providers.

This display should include, for each provider:

• name, icon, and domain name
• whether it is currently active, and a button to activate/deactivate
• whether it will be activated at browser startup
• whether notifications from the provider are allowed
• perhaps the most recent notifications? do we store them for a while?
• a way to delete the provider from the list

As a consequence of issue #1, when we re-activate the addon, it puts the sidebar in the wrong place (probably because "nav" is hidden).

Reflowing the layout fixes the issue; a fix for #1 might just clear this up.

We need a story for when the sidebar isn't visible (or for when a provider isn't the current provider) but the user is not logged in. I guess we would need some visual indication of that state in the toolbar area, and some action taken when they click on said indication.

We have talked about providing a JS or header-based cue to a site to let it know we are displaying a sidebar. Until we have that figured out, I think we should probably just auto-hide the sidebar when the user visits the provider's site.

How should this be implemented? We could use the prefixURL of the provider metadata, but that's more likely just the part of the site that implements the sidebar and serviceWindows. We could do a domain match, but that's likely to run afoul of http/https variation. Perhaps we should just match on the domain name.

Whatever we do to manage service provider metadata should evolve naturally from our Share implementation.

The social browsing popup should have a single-click way to switch between an active/inactive state.

When a service goes inactive, all of its serviceWindows should be closed, its Sidebars should be closed, and its Worker should be shut down. Any Sidebars that are displaying content from the provider should be closed (i.e. the sidebar element's browser should be set to a blank page, and the sidebar should be hidden). The Worker should be the last resource to close.

Open question: If the user has multiple service providers active and deactivates the currently visible one, should the sidebar switch to the next one in the list, or be hidden? Will flag as UX issue.

Open question: If there are serviceWindows open, should the user be given a chance to confirm before deactivating the service, since this will terminate the windows (which could mean cutting off a chat)?