• 4 out 11 tests for 'firefox_web' are failing on my machine.
• I installed all bundles and set up SQLite for my local web server. My server was responsive on localhost:3000 before I ran the integration tests
• I ran the ruby tests specific for firefox_web from ./privly-firefox/chrome/content/privly-applications/test/selenium.

Here is the prompt log:

You passed the arguments: {:platform=>"firefox_web", :release_status=>"experimental", :content_server=>"http://localhost:3000"}
Skipping due to release status: ZeroBin/new.html
Run options:

Running tests:

.....EE....

Finished tests in 180.214277s, 0.0610 tests/s, 0.0000 assertions/s.

1. Error:
   test_create_update_destroy(TestNew):
   Selenium::WebDriver::Error::WebDriverError: unable to bind to locking port 7054 within 45 seconds
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/socket_lock.rb:36:in lock' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/socket_lock.rb:17:inlocked'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/launcher.rb:32:in launch' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/bridge.rb:24:ininitialize'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/common/driver.rb:31:in new' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/common/driver.rb:31:infor'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver.rb:67:in for' /var/lib/gems/1.9.1/gems/capybara-2.4.4/lib/capybara/selenium/driver.rb:13:inbrowser'
   /home/niko/privly/privly-firefox/chrome/content/privly-applications/test/selenium/specs/tc_new.rb:11:in `setup'

2. Error:
   test_create_update_destroy(TestNew):
   Selenium::WebDriver::Error::WebDriverError: unable to bind to locking port 7054 within 45 seconds
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/socket_lock.rb:36:in lock' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/socket_lock.rb:17:inlocked'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/launcher.rb:32:in launch' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/bridge.rb:24:ininitialize'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/common/driver.rb:31:in new' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/common/driver.rb:31:infor'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver.rb:67:in for' /var/lib/gems/1.9.1/gems/capybara-2.4.4/lib/capybara/selenium/driver.rb:13:inbrowser'
   /home/niko/privly/privly-firefox/chrome/content/privly-applications/test/selenium/specs/tc_new.rb:78:in `teardown'

3. Error:
   test_creating_posts(TestNew):
   Selenium::WebDriver::Error::WebDriverError: unable to bind to locking port 7054 within 45 seconds
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/socket_lock.rb:36:in lock' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/socket_lock.rb:17:inlocked'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/launcher.rb:32:in launch' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/bridge.rb:24:ininitialize'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/common/driver.rb:31:in new' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/common/driver.rb:31:infor'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver.rb:67:in for' /var/lib/gems/1.9.1/gems/capybara-2.4.4/lib/capybara/selenium/driver.rb:13:inbrowser'
   /home/niko/privly/privly-firefox/chrome/content/privly-applications/test/selenium/specs/tc_new.rb:11:in `setup'

4. Error:
   test_creating_posts(TestNew):
   Selenium::WebDriver::Error::WebDriverError: unable to bind to locking port 7054 within 45 seconds
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/socket_lock.rb:36:in lock' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/socket_lock.rb:17:inlocked'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/launcher.rb:32:in launch' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/firefox/bridge.rb:24:ininitialize'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/common/driver.rb:31:in new' /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/common/driver.rb:31:infor'
   /var/lib/gems/1.9.1/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver.rb:67:in for' /var/lib/gems/1.9.1/gems/capybara-2.4.4/lib/capybara/selenium/driver.rb:13:inbrowser'
   /home/niko/privly/privly-firefox/chrome/content/privly-applications/test/selenium/specs/tc_new.rb:78:in `teardown'

11 tests, 0 assertions, 0 failures, 4 errors, 0 skips

We need a way of throttling injection of iframes when pages have thousands of Privly-type links. This could destroy browser performance.

Our headers must start with the X- prefix. Something like: X-Privly-Auth-Token

Add a form element to the preferences dialog that will allow users to manage the automatic injection list.

The steps involved in adding basic functionality include:

1. Adding a XUL text area to the preferences window
2. Implementing the Firefox Message Manager to connect the overlay with the content scripts.
3. Add a function in privly.js that will replace the privly.privlyReferencesRegex regular expression with the message sent by the extension, then re-runs privly.js.

This is a major deliverable of Masked

The IRC nickname "irdan" is working on this functionality.

I think malicious servers could potentially impersonate the chosen content server since the regular expression is not restrictive enough. We also need to make the sending of the auth_tokens capable of authorizing different servers, but this use case can wait until later.

    if (/priv.ly/.test(httpChannel.originalURI.host)) {
      httpChannel.setRequestHeader(privlyConstants.Strings.authToken, 
                                    this.preferences.getCharPref(privlyConstants.Strings.authToken), false);
    }
    else if (/localhost/.test(httpChannel.originalURI.host)) {
      httpChannel.setRequestHeader(privlyConstants.Strings.authToken, 
                                    this.preferences.getCharPref(privlyConstants.Strings.authToken), false);
    }

Latest version of everything
Mac OSX 10.7.3
Firefox 12.0
Priv.ly extension 0.1.6

I cannot and never could log into the Firefox extension. Error is 'We could not contact the Priv.ly servers [...]'.

I tried several times ever since I have an account with Priv.ly.

Logging into the Priv.ly web site always works, so it's not a problem with the account.

Please let me know if you need any more data.

Also, I volunteer for testing the Safari extension as soon as it reaches Beta.

Users should be able to select a form element they want to post to Privly with a right click or keyboard shortcut. This would bring up a form element in the privileged area of the browser window for the user to submit directly to the content or key host. The returned link will then be placed into the form area of the host page. The advantage of this is that it is protected from the host page, and it is clear that you are working with an extension. Many users will have difficulty telling where they can and cannot trust, but the "chrome" of the browser should eventually be recognizable.

JSON format pages don't need Privly links replaced.

We need to notify users of changes in the UI and functionality. Most extensions do this by presenting a document every time it updates. We should do the same.

I received the email found below about changes to the extension UI. I think this is a great time to refresh the UI using the new functionality. We could likely make the extension look and feel more like the Chrome extension since this update essentially Chrome-ifies the Firefox UI.

Hi,

Firefox 29 (the first version that implements the new Australis theme) will be released at the end of April, and it includes the addition of a menu panel and changes to the toolbar. From March 11 through April 15, we're challenging you to create add-ons that work great with the new design features. Prizes include Firefox OS phones and Mozilla gear, and a panel of judges will select three winners from each of three categories.

You can get the full details here: https://blog.mozilla.org/addons/australis-overview/, and we hope you compete!

Regards,
The AMO Team

It looks like the first-run page popping up on Firefox breaks testing on SauceLabs (but not locally). I think this is somehow breaking Selenium, but it is hard to say why. I am punting on this until later in the week since it is time to deploy.

This is a test...

We need to get a generic message interface into the iframes. It looks like there may be no way to use Firefox's built-in messaging system.

I asked a question on StackOverflow about this, but it hasn't gotten any traction.

Some potential options are:

• Encrypt the message with JavaScript AES and cascade the message through the host page context. This has many issues that would make us drop iframe support until version 5.
• Change the guts of Mozilla to add an API. This would be very difficult.
• Drop iframe support until subsequent versions.
• Keep experimenting and see if a solution presents itself. This is what I will work on as soon as I have time.

observers.js, authentication.js, and extension-host-interface.js should all be refactored into JS modules. This is going to be a blocking issue pretty soon, but no one is currently working on it. Comment for more information.

See: https://developer.mozilla.org/en/JavaScript_code_modules/Using

Starting from Firefox 4, Firefox supports extensions which can be installed/removed without restarting.

This mainly boils down to ensuring that the dynamic changes to the browser window happen on extension startup, and the extension is responsible for reverting those changes at shutdown.

I have started to make Privly restartless in this branch: https://github.com/ehsan/privly-firefox/tree/restartless

The major todo item is hooking up the Options dialog, but the rest of the basics should work fine. I didn't have a lot of time to hack on this today, so consider this branch as the skeleton. In particular I have not performed any testing as I don't have a bit.ly account yet (I've submitted a request for an invitation!).

Please feel free to pull in this branch, and build on top of it, or give me access to priv.ly so that I can test this and prepare it for a pull request myself.

We need a way to inform users what domain is displaying the non-white list content.

We currently set the extension version with a string in observers.jsm and other locations. We should set it with the Firefox API so it always tracks with the current version number.

Adding a keyboard shortcut adds usability for chat interfaces like gmail.

I have this feature mostly implemented using

document.activeElement;

however, if the active element is within an iframe, it returns the reference to the iframe instead of the actual active element. We probably need to use the Firefox API at the extension level to walk into the active iframe and get the active form element or editable div.

This can be implemented by adding a menu to, for example browser.xul:

<keyset id="mainKeyset">
    <key id="key_convert" key="x" modifiers="accel alt" oncommand="privlyExtension.keyboardCommand()"/>
</keyset>

Then adding the handler in extension-host-interface which asks for the cursor's current position using document.activeElement, and posts the content.

The extension is not running until Facebook is done with some slow network requests. It might have to do with the new onLoad start method.

Problem: Facebook (and likely others) submit the form element without the URL as updated by the extension. Currently, this will post the clear text to Facebook, and when we have the secure posting form, it will try to post empty contents. We need to simulate a user typing or pasting into a form element when we create new Privly posts. This will cause host pages to look for updated content in the form element.

We should trigger key press events (keydown, keypress, keyup, change) on the form element receiving the Privly link. Currently, this functionality belongs in the success callbacks defined within extension-host-interface.js.

  jQ.ajax({
    data: { auth_token: privlyAuthentication.authToken,
      "post[content]": value,
      "post[public]": postPrivacySetting,
      endpoint: "extension", browser: "firefox", version: "0.1.1.1"
    },
    type: "POST",
    url: contentServerUrl + "/posts.json",
    contentType: "application/x-www-form-urlencoded; charset=UTF-8",
    dataType: "json",
    accepts: "json",
    success: function (data, textStatus, jqXHR) {
      target.value = jqXHR.getResponseHeader("privlyurl");

      //
      //
      //trigger element change events here
      //
      //
    }
  });

Firefox: 14.0.1
Privly: 0.2.1
Website: Facebook.com (status update)

Step 1: In active mode, create a Privly link for the Facebook status.
Step 2: Click "Post", without "x"ing out the preview.

Outcome: http://imgur.com/mq7hv

It's all kinds of wonky...

The select conversation drop down in the upper left of Facebook's menu bar is being replaced, which prevents clicking through to the conversation history page.

The context menu for posting anonymous content is being displayed regardless of whether the user has right-clicked a form element. The context menu should only display when the user clicks a form element.

The Chrome extension's nacl branch defines a JSON interface between the compiled library and the extension's context. It is time to package an XPCOM component for the extension and implement the same message passing style.

The Opera version has a few changes to privly.js, mostly to be in more strict compliance with web standards (I believe). We should copy these changes back into the Firefox version.

Your fork does not run on TravisCI by default so you don't run all the integration tests on every "push".

This can be very confusing. This issue is for helping people setup TravisCI with SauceLabs. Comment if the documentation for continuous integration is not sufficient and you need help. We will then translate any issues or misconceptions into changes in the documentation.

Mozilla has continued to develop the Jetpack extension framework for Firefox to the point that it has parity with XUL based extensions for our feature set. Since Jetpack makes many extension tasks vastly simpler, more secure, and better supported, it is time to port the Firefox extension to Jetpack!

This introduces several dilemmas as we push towards release, most importantly whether we continue developing and supporting the current version of the Firefox extension so we can support Firefox at launch. My plan is to make minimal changes so that the current UI of the Firefox extension will continue to function until we finish porting to Jetpack. I estimate porting to Jetpack would take me about a week of dedicated time or a newbie about 12 weeks of dedicated effort to work through.

Content Security Policy mitigates a large number of potential vulnerabilities. The Chrome extension implements it by default, but implementation on Firefox will not be native until this bug is closed. Until Mozilla implements it natively, we can add a module that will enforce it. See SO.

The way that the http request/response observers are currently registered is sub-optimal. Right now, observers.js is included in browser.xul, which means that it is loaded once per every browser window you open. So, if you have two browser windows open, you will have two of each one of the observers, which is unnecessary overhead.

The standard way of doing this properly is to use a js module: https://developer.mozilla.org/en/JavaScript_code_modules. Javascript modules are loaded only once, and you can access them from multiple browser windows if needed.

Please let me know if you need help with converting the existing code to a module.

The privly-chrome extension sports an improved posting mechanism and needs to be ported. See this pull request for details.

This StackOverflow question gives one possible way of adding locally-served injected applications. This method would require the ability to traverse the DOM into iframes from the extension's context. This has always been problematic.

This is an entry level issue for users to become familiar with the Privly Project's code base. You should pick a file from CodeClimate and improve files per the recommendation of the programmatic code quality system.

Do not close this issue in your commits since this is intended to be a more permanent issue.