Initial functionality for the chat window is a chromeless window with a xul:browser that loads content from a provider. - we ensure the loaded content is over ssl with a valid cert required - no ssl indicators will be used in the window - there is an api, implemented in Provider.jsm, available to social iframes allowing the window to be opened from *visible* content
Created attachment 639512 [details] [diff] [review] servicewindow.patch An implementation for the service window (chat) that doesn't require all the xul/js/module stuff we've been using. Much simpler, and potentially throw away when we redo chat for 17. Tests will require the provider class landed, so waiting on that, looking for early review and feedback.
another note on this patch, getWebProgressListener is exported since it can be used by the sidebar or other content area's to ensure the content area remains same-origin to the provider.
Created attachment 639537 [details] [diff] [review] servicewindow.patch minor bug fix, some renaming of vars to be clear
*** Bug 755125 has been marked as a duplicate of this bug. ***
Created attachment 640493 [details] Mockup: Simplified chat window on OSX and Windows Drawing our own serviceWindow gives us the control over the widgets and interface of chat windows that we've previously lacked, correct? While the chat windows won't be able to minimize to the browser window in v1, making their chrome more minimal and more integrated with Firefox's design will go a long way towards their usability.
Shane, is this patch ready for a review? Can you set that request if so?
(In reply to Asa Dotzler [:asa] from comment #6) > Shane, is this patch ready for a review? Can you set that request if so? There is a line of bugs with patches for review prior to this one. I am currently reworking this patch on top of those.
Created attachment 642037 [details] [diff] [review] servicewindow.patch initial chat window implementation for feedback
Created attachment 645121 [details] [diff] [review] updated patch still needs tests
Comment on attachment 645121 [details] [diff] [review] updated patch Here are a couple of comments: - no need to put openServiceWindow in its own module, just put it in mozSocialAPI directly. - let's get rid of the webprogresslistener for now (per in-person discussion) - rather than newURI(aTargetWindow.location.href, ...), you can use aTargetWindow.document.documentURIObject - need tests
Created attachment 645499 [details] [diff] [review] revised patch with tests
Created attachment 646024 [details] [diff] [review] slightly modified patch, with additional test Same patch, just made a few tweaks, and added a test for the double-window case. I was a bit afraid about the use of getWindowByName, so I added a prefix to the name, and specified the "aCurrentWindow" argument to getWindowByName. I also renamed runTests to runSocialTests when moving it to head.js, because it otherwise conflicts with existing "runTests" in other tests.
https://hg.mozilla.org/mozilla-central/rev/9d8cc914ad36
or
