J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Description • 10 years ago

For WiFi debugging, we intend to exchange keys via a QR code that is scanned with the phone.

To support this, we need to decode a QR code.

There appears to be one main JS decoder[1].  I'll wrap it with a simple API.  The decoder is under the Apache 2.0 license, which the licensing FAQ suggests doesn't require an explicit review.

[1]: https://github.com/LazarSoft/jsqrcode

	Paul Rouget [:paul]
	Comment 1 • 10 years ago

Just a thing to consider: do we want this code in gecko or in gaia?

	Mark Finkle (:mfinkle) (use needinfo?)
	Comment 2 • 10 years ago

Firefox for Android would be interested in a QRCode reader. We could use a Java one, but maybe a Gecko one would be more useful.

	Richard Newman [:rnewman]
	Comment 3 • 10 years ago

Dupe or dependency of Bug 602818?

And for Sync, my first bug at Mozilla back in 2010: Bug 603882.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 4 • 10 years ago

I plan to have Gecko offer an API that takes in an image src (can be data URI, blob URI, etc.) and gives you back the data inside.  This way the decoding part is easily shared between FxOS, Fennec, and whoever else.

The actual UI to scan a QR code will differ between platforms.  For example, in the FxOS case, it will be part of Gaia.  A similar approach should work with Fennec too.

At the moment, I'll be putting the library in DevTools code.  I'll file a separate bug to work out if a different location is needed for non-DevTools usages of QR decoding, and have bug 602818 depend on it.

	Richard Newman [:rnewman]
	Comment 5 • 10 years ago

Sounds like a good starting point! 

We'll have to see on Fennec whether it harms the UX too much to wait five or ten seconds for Gecko to start -- we might end up needing QR codes in Sync, and those two things might be enough to tip us into using a Java QR library. Fingers crossed.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 6 • 10 years ago

Similar to the encoder bug, this adds an external library that I've modified only a little to make it accessible as a module.

The QR wrapping module is extended with decoding operations.

A few files from before are also renamed.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 7 • 10 years ago

Try: https://tbpl.mozilla.org/?tree=Try&rev=123ffa5ab9c6

	Paul Rouget [:paul]
	Comment 8 • 10 years ago

Comment on attachment 8418468 [details] [diff] [review]
Add QR decoder library

What about using nsAppShellService::CreateWindowlessDocshell to get access to a window instead of using Services.wm.getMostRecentWindow?

maybe you want to rename **coder/index.js to **code/**coder.js.

s/jryans/mozilla/

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 10 • 10 years ago

Do you mean nsAppShellService::CreateWindowlessBrowser?

I tried using it in the following way:

const { Cc, Ci } = require("chrome");
const appShellService = Cc["@mozilla.org/appshell/appShellService;1"]
                        .getService(Ci.nsIAppShellService);
const webNavigation = appShellService.createWindowlessBrowser();
const window = webNavigation.document.ownerGlobal;
const { document, Image } = window;

The functions correctly, but it seems to keep the window alive, causing an ABORT in debug builds (see stack trace in attachment 8418962 [details]).

Do I need to explicitly release / destroy the window in some way?  An an aside, I didn't see any callers of CreateWindowlessBrowser aside from a test, so I wasn't sure if this is right use case for this ability.

	Paul Rouget [:paul]
	Comment 11 • 10 years ago

Nobody uses this because it's (kinda) new feature (and designed for tests iirc).
And what about using Services.appShell.hiddenDOMWindow?

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 12 • 10 years ago

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #8)
> maybe you want to rename **coder/index.js to **code/**coder.js.

I thought about this, but didn't really like saying require(.../decode/decoder), and I think it's cleaner to have separate dirs for the decoder and encoder since they have their own licenses.

Also, index.js style might soon be recognized by the loader automatically if we enable node-style resolving[1].

> s/jryans/mozilla/

Makes sense, done!

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #11)
> Nobody uses this because it's (kinda) new feature (and designed for tests
> iirc).
> And what about using Services.appShell.hiddenDOMWindow?

Okay, that seems to work, thanks!

[1]: http://dxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/toolkit/loader.js#441

I'll eventually post to Try if it lets me...

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 13 • 10 years ago

Try: https://tbpl.mozilla.org/?tree=Try&rev=de02d9eca6d2

	Ryan VanderMeulen [:RyanVM]
	Comment 14 • 10 years ago

https://hg.mozilla.org/integration/fx-team/rev/5fd2e583adc0

	Carsten Book [:Tomcat]
	Comment 15 • 10 years ago

https://hg.mozilla.org/mozilla-central/rev/5fd2e583adc0