602818 - Integrate QR code scanner into Fennec

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, enhancement)

Description

[Irina Sandu]

QR codes have become very popular lately and their main purpose is to redirect to a web page or initialize a download, which are both done from the browser. Thus, why not have the QR code scanner directly in the browser? 

This makes even more sense when using camera controls through Fennec. When encountering a QR code, user does not have to leave the browser, but takes the picture and scans it directly in Fennec. 

One could argue that the QR code scanner might be a good add-on, but the process is equivalent to tapping on a link (which triggers redirect/download), which is a native browser feature. I understand QR codes as a richer alternative to <a href> and with their increasing popularity it makes sense for me that a scanner is included in Fennec.

Comment 1

[Yuan Xulei [:yxl] (Leave from May 18)]

I'd like to work on this feature.

QR code is quite popular in China and Japanese. Websites and mobile apps provide QR code on various media to let user access the websites and download the apps through phone camera. 

The most popular Chinese mobile browser - UC browser, which claimed of 200+ million users, integrate scanner to allow user to load a webpage by its QR code.

Comment 2

[Richard Newman [:rnewman]]

Ian, do you have any thoughts on how you would integrate this with your plans for the UI?

(I wonder if it makes sense as an optional home screen tile...)

Comment 3

[Karen Rudnitski [:kar]]

I'm feeling that this sounds like a great add-on idea, and we can gauge the add-on success first before integrating it as a feature for the global product. Can we go down this path to get this bug off the ground?

Comment 4

[Richard Newman [:rnewman]]

(In reply to Karen Rudnitski [:kar] from comment #3)
> I'm feeling that this sounds like a great add-on idea, and we can gauge the
> add-on success first before integrating it as a feature for the global
> product. Can we go down this path to get this bug off the ground?

It makes sense to me, if there's enough UI, camera, and imaging capability exposed to add-ons.

(If not, there probably *should* be, but it does grow the scope of this work!)

Comment 5

[Karen Rudnitski [:kar]]

I think it's good to scope out these dependencies and requirements, and we can work on making the add-on experience better. There is no rush for implementation so we can ensure that we do this right!

Comment 6

[Yuan Xulei [:yxl] (Leave from May 18)]

I don't think add-on is a feasible idea. 

We don't have necessary camera and imaging capability exposed to add-ons to fulfil code scanning and decoding. It needs much work to do exposing necessary APIs.

Fortunately it already exists mature and stable android solution(http://code.google.com/p/zxing/) for us. We can integrate it into Fennec with quite little effort.

Directly embedding the QR scanner is a low cost, but will bring much convenience to our users and can make a difference with other mobile browsers as well.

Besides, we can also use QR code to simply the process of paring a sync device. Currently user is required to enter 12-character pass-code to pair a phone with a PC. We can use QR code to encode the pass-code, and let users scan the QR code with their phone without entering 12 characters.

Comment 7

[Richard Newman [:rnewman]]

(In reply to Yuan Xulei [:yxl] from comment #6)

> Directly embedding the QR scanner is a low cost, but will bring much
> convenience to our users and can make a difference with other mobile
> browsers as well.

I think Karen's point is that QR codes don't have widespread adoption in most regions, and so the short- and long-term costs of integrating a QR code scanner -- code size, build time, code complexity, testing and validation, UX design and maintenance, and even future community pain on removal -- aren't currently offset by enough user benefit to justify mainline inclusion in the product.

As an explanation for why Karen and I don't immediately agree with your assessment of "low cost":

<http://firstround.com/article/The-one-cost-engineers-and-product-managers-dont-consider#>

And as a humorous aside, this is what most of the western world thinks of QR codes: <http://www.globalnerdy.com/2013/04/07/should-you-use-a-qr-code/>

This doesn't mean that you can't throw together a huge patch bomb that implements this feature. It does mean that if you *do*, it'll have to be so phenomenally persuasive that myself, the other module peers, and Karen think that those long-term costs -- which you won't have to bear -- are worth paying.

Furthermore, we'd like to be in a situation whereby you *can* build a QR code scanner as an add-on for Firefox, because it'll indicate that our camera and image processing facilities are competitive.

If you spec out the list of dependencies that you'd need met before you could ship this as an add-on -- e.g., "I need control of camera focus from JS" -- then you'll get more support from the product owners. Worst case, we decide that it indeed isn't possible to deliver these capabilities for an add-on, and that simplifies the decision-making process.

Finally, what about doing something like launching a system-wide QR code reader?

http://stackoverflow.com/questions/15833596/intent-createchooser-android-qr-code-reader

> Besides, we can also use QR code to simply the process of paring a sync
> device. Currently user is required to enter 12-character pass-code to pair a
> phone with a PC. We can use QR code to encode the pass-code, and let users
> scan the QR code with their phone without entering 12 characters.

Amusingly enough, that was my first bug when I joined Mozilla. We WONTFIXed it the same week.

Bug 603882.

There are other plans in the pipeline to improve the Sync setup experience, so we can scratch this off the list for now.

Comment 8

[Wesley Johnston (:wesj)]

> We don't have necessary camera and imaging capability exposed to add-ons to
> fulfil code scanning and decoding. It needs much work to do exposing
> necessary APIs.

I actually think you can do most of what you need with WebRTC. In fact, we have a demo of scanning QR codes from a web page somewhere around.

> Fortunately it already exists mature and stable android
> solution(http://code.google.com/p/zxing/) for us. We can integrate it into
> Fennec with quite little effort.

I think you should also be able to use this if you wanted. If you can compile some of zxing into a jar, it should be loadable using NativeWindow.loadDex("path/to/jar", "myZxingClass"). If you're interested, there are some guys on irc (kats and sriram) who have some experience doing this.

We don't have good hooks into the awesomescreen for addons. So (for instance) adding a button to show a qr code reader next to the urlbar would be relatively tough... One-size-fits-all UX definitely isn't great (especially when it comes to languages and typing on small screens), so I'd be happy to help if we can.

> Finally, what about doing something like launching a system-wide QR code reader?

I agree with the bug-filers that Android's "just fire up an intent and let someone else do it" makes for a relatively awful user experience of constantly changing context and ux. i.e. this seems like a less than ideal solution.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

Yuan - Based on some tech press, I see that QR codes are pretty popular in China and Japan:
http://techcrunch.com/2013/05/29/people-actually-use-qr-codes-in-china/
http://thenextweb.com/asia/2013/05/09/visualead-launches-its-near-invisible-qr-codes-in-china-seeks-local-partners-and-investors/

Even so, this would be almost unused by western Firefox users. Like Richard and Karen, I want to see how we could build such a tool as an add-on before adding the code for all users.

Some questions:
* How would you like this to work? Would the user press a menu and that would open the camera. Once the picture is taken, we'd analyze the QR code (if there is one) and navigate to the page.
* What level of QR code support do we need to consider? I see a lot of different QR code formats.
* I found a JavaScript port of the ZXing code here: https://github.com/LazarSoft/jsqrcode

The JS code might make creating an add-on easier. We do support using Java code in add-ons too, but it looks like the ZXing library is a lot of code. It could add some size to the APK.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Wesley Johnston (:wesj) from comment #8)

> > Finally, what about doing something like launching a system-wide QR code reader?
> 
> I agree with the bug-filers that Android's "just fire up an intent and let
> someone else do it" makes for a relatively awful user experience of
> constantly changing context and ux. i.e. this seems like a less than ideal
> solution.

I don't necessarily agree with the awful UX of using intents to spawn off to a separate app. It's the core of Android, and it works pretty well for lots of things :)

Comment 11

[Yuan Xulei [:yxl] (Leave from May 18)]

Sorry for the late reply.

Richard, Wesley and Mark, thanks for your information. I'll try to make a demo scanner as an add-on with the support of WebRTC.

(In reply to Mark Finkle (:mfinkle) from comment #9)
> Some questions:
> * How would you like this to work? Would the user press a menu and that
> would open the camera. Once the picture is taken, we'd analyze the QR code
> (if there is one) and navigate to the page.
User will either press an option menu item or a home screen tile(as Richard suggested) to open the camera. We'd scan and analyze the video in real time until we decode the QR code. (During the scanning, we may need adjust the focus.) If the QR code content is a URL, we
will navigate to that page. Otherwise if the content can be a keyword, we can search it on the web. 

> * What level of QR code support do we need to consider? I see a lot of
> different QR code formats.
I think it is enough to support QR code model 1 and 2(http://www.qrcode.com/en/codes/), which are the mostly used.

> * I found a JavaScript port of the ZXing code here:
> https://github.com/LazarSoft/jsqrcode
> 
> The JS code might make creating an add-on easier. We do support using Java
> code in add-ons too, but it looks like the ZXing library is a lot of code.
> It could add some size to the APK.
It is helpful and convenient for processing the image captured from camera if the JS code is fast enough.

Comment 13

[James Hugman [:jhugman] [@jhugman]]

Coming to this bug a little late on. I'm very reluctant to do anything other than calling out to an intent. We can detect that the intent will be called, and deal with the case then.

I don't understand why we should add a QR code library, rather than call out to an intent. 

Using an intent requires one of two fall back strategies:

 * hide the call to action if the intent isn't callable.
 * link to market://details page if the intent isn't callable, after the user has called the call to action.

I get that it's to allow us to depend on a QR scanner being present. And potentially brand the QR scan. 

My hunch (i.e. no data) is that users who use QR codes on their phone will have a QR scanner app already.

For the minority who don't (i.e. want a qr code scanner, we can offer a market:// link to ZXing). This is the Android way.

Do we have the telemetry/data available for which QR scanners are popular in our target territories?

Comment 14

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to James Hugman [:jhugman] [@jhugman] from comment #13)
> Coming to this bug a little late on. I'm very reluctant to do anything other
> than calling out to an intent. We can detect that the intent will be called,
> and deal with the case then.
> 
> I don't understand why we should add a QR code library, rather than call out
> to an intent. 

What intent would we use?


> For the minority who don't (i.e. want a qr code scanner, we can offer a
> market:// link to ZXing). This is the Android way.

You could argue that the "Android Way" would be to call out to an intent (if a QR code intent even exists), but fallback to a built-in library. Forcing people to go to the Play Store to complete a task isn't the best UX.

> Do we have the telemetry/data available for which QR scanners are popular in
> our target territories?

That is a good question. NI'ing Product.

Comment 15

[Richard Newman [:rnewman]]

The top QR code scanners on Google Play:

100-500M installs
https://play.google.com/store/apps/details?id=com.google.zxing.client.android

10-50M installs
https://play.google.com/store/apps/details?id=me.scan.android.client
https://play.google.com/store/apps/details?id=la.droid.qr
https://play.google.com/store/apps/details?id=appinventor.ai_progetto2003.SCAN

5-10M installs
https://play.google.com/store/apps/details?id=jp.eqs.apps

1-5M installs
https://play.google.com/store/apps/details?id=tool.scanner
https://play.google.com/store/apps/details?id=com.scanner.barcodescan


Often these apps seem to include ads. They (perhaps obviously) also seem to be intended to go the other way: that is, you scan with them, then it sends the appropriate intent. The experience is poor if you don't start in the scanner app.

Here's how ZXing thinks you should do it:

https://github.com/zxing/zxing/wiki/Scanning-Via-Intent
http://stackoverflow.com/questions/15833596/intent-createchooser-android-qr-code-reader

I have some apprehension about successfully transitioning to a scanner app and back again on low-memory devices.


I see three choices:

* Use ZXing's intent chooser (see link above).

* Embed ZXing to do scanning in the app itself: https://github.com/journeyapps/zxing-android-embedded. Better experience but fatter APK.

* Somehow call into Gecko to use its QR code reader.

Comment 16

[Yuan Xulei [:yxl] (Leave from May 18)]

FYI, in China, most people use WeChat(https://play.google.com/store/apps/details?id=com.tencent.mm) to scan QR code without a standalone QR scanner app. 

WeChat is a text and voice messaging communication app like WhatsApp. It has 500M users in China and 100M users in other countries by the end of 2nd quarter of 2014. Since most Chinese users cannot access google play, we get 100-500M installs, which are mainly from users outside China.

Considering these Chinese users, calling out to ZXing intent is of poor experience.

I think the other two options rnewman provided are better:

* Embed ZXing
* Use gecko QR code reader

I prefer embeding ZXing. We had a telemetry data before about the way people using barcode scanner. The data shows 95% scanning are QRCode of URL in China. So for these users, we could strip off other functions other that URL QRCode scanner to shrink the ZXing size effectively.

The reason I don't prefor using gecko QRCode reader is that QRCode scanning is a dynamical process. People need to change the camera focus and process lost of QRCode images in real time for one scanning. The gecko QRCode reader is only QR image decoder and we need to do extra work to deal with the dynamical process before passing image data to the reader. Also it harms the UX to wait five or ten seconds for Gecko to start and load the reader.

Comment 17

[Richard Newman [:rnewman]]

I have many of the same concerns, yxl, so embedding is also my preferred approach.

That said, now is probably the right moment to mention space concerns.

I'm expecting a solution here that's modular and couched in enough build flags to allow us to ship an alternative intent-based option in resource-constrained devices -- the difference is 200KB of code, which is significant. Or to not ship the feature at all (mainly something that third parties care about).

Comment 18

[James Hugman [:jhugman] [@jhugman]]

Ok, that sounds like a plan, rnewman in comment 17. Thanks for the details, yxl and rnewman.

Further out, I'm still curious as to how this fatter binary pattern scales, other than devices getting bigger.

yxl: I'm aware that the Play store isn't available in China - the Play Store (and Yandex, Amazon and a few others) offer market://details?id= intents. What markets are available, and what intents to install a package do they support?

What markets are available: https://github.com/onepf/AppDF/wiki/Android-Application-Stores provides an overview, but I can't verify any of it.
What market://details?id= intents (or equivalent) are supported by each of them? (perhaps these questions aren't suitable for this bug).

Comment 19

[James Hugman [:jhugman] [@jhugman]]

I'm looking at putting https://github.com/journeyapps/zxing-android-embedded into the Fennec build.

The current build is such that if it's just code, then fine, but if it has resources then you're going to be sad. 

https://github.com/journeyapps/zxing-android-embedded has a bunch of resources, so I'm going to be sad.

So I have some approaches to this: 
 * alter the zxing project to have no resources, or move the resources (& change the code) to have resources in the fennec (Java) package.
 * alter our build to accommodate a library with resources (somehow)
 * find some other embedded library.

It is fairly standard practice to distribute resources with libraries now, so looking for another library with the quality of ZXing is somewhat fruitless. They may exist, but I haven't found it yet.

I am generally against the idea of changing code that we're importing, by hand. The reasons for this distaste shouldn't be surprising.

So we are left with two approaches to ingest the library with resources:

 * a one shot import process to get the project into the file layout our build likes. This would likely be by hand.
 * a repeatable (part of the build) step to do the same.

What the import looks like:
 * moving resources around, re-writing references in source code to the R class etc.
 * taking pre-compiled aar files and unpacking them and putting those artifacts into the correct place
 * using this as an excuse to get gradle further into the build. 

I'd prefer not to do this sort of thing by hand. Although I can't decide what the least bad approach is, I think this is the most bad approach.

I'm also wary of that we don't want ot be duplicating features (badly) of an already existing build system that we already use.

What is the least bad thing to do?

mobile/android/base/build.mk
mobile/android/mach_commands.py
mobile/android/base/Makefile.in

Comment 20

[Nick Alexander :nalexander [he/him]]

(In reply to James Hugman [:jhugman] [@jhugman] from comment #19)
> I'm looking at putting https://github.com/journeyapps/zxing-android-embedded
> into the Fennec build.
> 
> The current build is such that if it's just code, then fine, but if it has
> resources then you're going to be sad. 
> 
> https://github.com/journeyapps/zxing-android-embedded has a bunch of
> resources, so I'm going to be sad.
> 
> So I have some approaches to this: 
>  * alter the zxing project to have no resources, or move the resources (&
> change the code) to have resources in the fennec (Java) package.
>  * alter our build to accommodate a library with resources (somehow)
>  * find some other embedded library.
> 
> It is fairly standard practice to distribute resources with libraries now,
> so looking for another library with the quality of ZXing is somewhat
> fruitless. They may exist, but I haven't found it yet.
> 
> I am generally against the idea of changing code that we're importing, by
> hand. The reasons for this distaste shouldn't be surprising.
> 
> So we are left with two approaches to ingest the library with resources:
> 
>  * a one shot import process to get the project into the file layout our
> build likes. This would likely be by hand.
>  * a repeatable (part of the build) step to do the same.
> 
> What the import looks like:
>  * moving resources around, re-writing references in source code to the R
> class etc.
>  * taking pre-compiled aar files and unpacking them and putting those
> artifacts into the correct place
>  * using this as an excuse to get gradle further into the build. 
> 
> I'd prefer not to do this sort of thing by hand. Although I can't decide
> what the least bad approach is, I think this is the most bad approach.
> 
> I'm also wary of that we don't want ot be duplicating features (badly) of an
> already existing build system that we already use.
> 
> What is the least bad thing to do?

I looked at the zxing-android-embedded library and it displays a good deal of UX (so requires resources) and uses some non-trivial Gradle packaging features (multiple resDirs).  It will be a pain to integrate its resources into Fennec, but not impossible.

I have read the discussion above, and I don't see a clear argument for why we we would not integrate via intents: https://github.com/zxing/zxing/wiki/Scanning-Via-Intent.  The strongest argument I see is rnewman's concern that we couldn't transition from Gecko to Barcode Scanner to Gecko on low-memory devices.

If we are convinced that we should integrate a library rather than scan via intents, then I think the best action is for me to put some time into integrating the ZXing AAR into the existing build system.  I would love to push on building with Gradle, but it is time-consuming and high risk.  We have some integrations (Google Play Services) that are AAR-like, and I understand what has to happen, it just won't be pretty.

Comment 21

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Nick Alexander :nalexander from comment #20)

> I have read the discussion above, and I don't see a clear argument for why
> we we would not integrate via intents:
> https://github.com/zxing/zxing/wiki/Scanning-Via-Intent.  The strongest
> argument I see is rnewman's concern that we couldn't transition from Gecko
> to Barcode Scanner to Gecko on low-memory devices.

I think comment 16 has some additional information as to why we would like to avoid it.

Comment 22

[Mark Finkle (:mfinkle) (use needinfo?)]

I do have questions about embedding though:

Are we embedding just the minimum core required to decode QRCodes?

Are we pulling in the entire Barcode Scanner application?

What do we expect the UX to be once we tap the "qrcode" button in Fennec? If we want to control aspects of the UX, I assume we need to depend less on the resources of ZXing and more on our own code.

Comment 23

[Mark Finkle (:mfinkle) (use needinfo?)]

I chatted with Nick a bit about this work. We decided that an iterative approach might be useful:

1. We don't have a lot of time or resources
2. We do have a lot of higher priority work to do
3. We could use the Intent based approach as a first iteration
4. We could test out #3 behind a NIGHTLY flag and see how the UX feels
5. Later, we can work toward embedding the library into Fennec and shipping it.

Unless anyone has issues with this plan, let's use this bug to get #3 and #4 ready to go. Then #5 can be a new bug.

Comment 24

[Yuan Xulei [:yxl] (Leave from May 18)]

It sounds great!

Comment 25

[James Hugman [:jhugman] [@jhugman]]

Attachment: Work in progress patch calling out to ZXing.

Work in progress. Added call out to the ZXing, without using the IntentIntegrator.java and IntentResult.java.

1) if the feature is optional, user should be able to turn it off.
2) if/when there is no barcode scanner, when should we help the user through the process. (options – at first use, or as part of the turning the QR Code on)
3) What happens when the QR code is scanned? The predominant use case is a URL scan. Should we be doing search suggestions?
4) Putting this button in the toolbar is just to demonstrate scanning works.
5) icons in mobile/android/base/resources/drawable-*/ab_qrcode.png. These are I hacked together and shouldn't be considered final.
6) We have limited scope to change the Capture Activity, including title.

Comment 26

[Martyn Haigh (:mhaigh)]

Comment on attachment 8575381 [details] [diff] [review]
Work in progress patch calling out to ZXing.

Review of attachment 8575381 [details] [diff] [review]:
-----------------------------------------------------------------

Looking good to me, seems to work well.

::: mobile/android/base/toolbar/ToolbarEditText.java
@@ +755,2 @@
>          private Drawable mVoiceSearchIcon;
> +        private final Drawable mQrCodeIcon;

nit: 'QR' - this is more consistent with the current format (sadly) - here and elsewhere

Comment 27

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Comment on attachment 8575381 [details] [diff] [review]
Work in progress patch calling out to ZXing.

Review of attachment 8575381 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the delay - getting caught up with my own plate. Looks like a good approach to me!

> nit: 'QR' - this is more consistent with the current format (sadly)

*Happily - I suppose we all have our preferences. :)

::: mobile/android/base/toolbar/ToolbarEditText.java
@@ +511,5 @@
> +    private void launchQrCodeReader() {
> +        final Intent intent = createQrCodeReaderIntent();
> +        Log.i(LOGTAG, "Calling QRCode: " + intent);
> +        Activity activity = GeckoAppShell.getGeckoInterface().getActivity();
> +        ActivityHandlerHelper.startIntentForActivity(activity, intent, new ActivityResultHandler() {

Does this open a chooser if there are multiple activities to handle the action? If not, it probably should - I vaguely remember talk that other QR code readers share zxing's action.

Comment 28

[James Hugman [:jhugman] [@jhugman]]

If multiple activities are available, the standard chooser is shown.

Comment 29

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Apologies James, still haven't had time to get to this. Will try to get caught up next week.

Comment 30

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

If we're requiring users to have another Application installed in order to see this (kind of like the UX for the Android guy), do we have any plans to communicate this message to the user more prominently? I.e. via marketing, messaging on their end, etc? otherwise this would be immensely non-discoverable.

Will chat with Karen about this a bit more. Stay tuned.

Comment 31

[James Hugman [:jhugman] [@jhugman]]

Attachment: Screen shot showing position of QR code button.

Comment 32

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to James Hugman [:jhugman] [@jhugman] from comment #31)
> Created attachment 8586079 [details]
> Screen shot showing position of QR code button.

Where are we getting this icon from? 

We should align it to the left hand side of the voice mic icon :)

Comment 33

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: QR_flow1.png

Attaching overall UX flow so we can have basis for conversation. Right now, we're focusing on the post-Google Play experience. Basically, if they have the right app, they will see this icon in the toolbar.

Still to-do for UX:

 - Supply QR code icon for URL bar
 - Define "Settings" UI for enabling/disabling this feature (for users that have the QR reader app)

Note: Error and success feedback (from my experience) are provided by the QR reader themselves so we don't have to have one on our side. It should just work, or the user has to back out of the app themselves.

Did I miss anything?

Comment 34

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: icon_mob_QR.zip

QR scan icon attached. 

Let's stick this in there on the left side of the Voice Input icon and see how it looks. Could you attach a screenshot when you get the chance James?

Padding between the voice mic icon and the edge of the input box should be kept consistent on both sides.

Comment 35

[Chenxia Liu [:liuche]]

I'm going to assign this to karim for now, since there doesn't look like there's been activity for a couple of months.

Comment 36

[Chenxia Liu [:liuche]]

To summarize, Karim you should try out the patch that is in this bug - it should do most of the work that is needed. You'll also need to install that QR reader (ZXing). This will probably be bitrotted (likely by your voice integration changes :P) so you'll have to resolve some conflicts.

What remains to be done on this bug is to put the icon to the left of the voice input icon (but to the right of the url content). Currently, the voice icon is being set as a compound drawable, but that only allows one icon, so you'll have to add another view that is shown/hidden appropriately. You can take a look at the "reader mode" icon (that shows up on articles) to see how you might do that.

Comment 37

[Chenxia Liu [:liuche]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3e6d67df0b7d

Comment 38

[Karim Benhmida [:karim]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3ea7d56a8d73

Comment 39

[Chenxia Liu [:liuche]]

https://hg.mozilla.org/integration/fx-team/rev/9f307a1aba5c

Comment 40

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9f307a1aba5c

Comment 41

[Lawrence Mandel [:lmandel] (use needinfo)]

Release Note Request (optional, but appreciated)
[Why is this notable]: New way to enter URL in Firefox
[Suggested wording]: Scan an URL from a QR code from the search panel
[Links (documentation, blog post, etc)]:

Landed in 41 but not enabled. Note is currently disabled in Nucleus and can be re-enabled if the feature is preffed on in 41.

Comment 42

[DongShengXue]

Attachment: Qrcode patch in China edition

This patch embed the QR scanner(Zxing) in China edition directly.

Comment 43

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8631394 [details] [diff] [review]
Qrcode patch in China edition

Ah, by merging the zxing resources into the Fennec resources.  It would be unfortunate to do this, but it is one way to move forward.

Comment 44

[DongShengXue]

Attachment: Qrcode patch in China edition

Qrcode patch in China edition

Comment 45

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #41)
> Release Note Request (optional, but appreciated)
> [Why is this notable]: New way to enter URL in Firefox
> [Suggested wording]: Scan an URL from a QR code from the search panel
> [Links (documentation, blog post, etc)]:
> 
> Landed in 41 but not enabled. Note is currently disabled in Nucleus and can
> be re-enabled if the feature is preffed on in 41.

We should relnote this for FF42. More info at https://bugzilla.mozilla.org/show_bug.cgi?id=1182220#c14.

Comment 46

[Sylvestre Ledru [:Sylvestre]]

Added to the release notes with Lawrence wording.
I will update the note when/if we have some user doc.

Comment 47

[Biraj Karmakar [:biraj]]

Hi all

I have going to start draft a SUMO article for that. 

Biraj

Comment 48

[Biraj Karmakar [:biraj]]

Have one doubt

Actually I have used this feature in my phone. 

But what I have faced here without this application https://play.google.com/store/apps/details?id=com.google.zxing.client.android app in my phone, QR scanner optionis not coming. After installation of that app, then only I am getting QR scanner option left side of the mic in URL box. 

So that means when I am going to write SUMO for this article we have to mention about following QR scanner application. Though I don't know about the QR scanner application policy and all.

Am I on the right track or not?

Please confirm. SO I can start writing.

Any help appreciated here.

Comment 49

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Biraj Karmakar [:biraj] from comment #48)
> So that means when I am going to write SUMO for this article we have to
> mention about following QR scanner application. Though I don't know about
> the QR scanner application policy and all.
> 
> Am I on the right track or not?

I'm not sure I fully understand, but I'll try to answer.

> But what I have faced here without this application
> https://play.google.com/store/apps/details?id=com.google.zxing.client.
> android app in my phone, QR scanner optionis not coming. After installation
> of that app, then only I am getting QR scanner option left side of the mic
> in URL box. 

This is expected behavior – the QR code icon will appear when you have the QR code application installed and it won't appear when you don't have the QR code application installed. The only accepted QR code application as of bug 1182220 is Zxing, though we can explicitly add others later.

afaik, we do this because certain locales (e.g. China?) frequently use QR codes in the browser, in which case the application will be pre-installed and the QR code icon present. Otherwise, the QR code application is not installed and the icon hidden (e.g. in the US locale, a QR code reader is not desirable in the browser so we don't want it taking up space in the already small toolbar).

Comment 51

[Julien Wajsberg [:julienw]]

It's a bit sad that the only app we can use (from zwing) requests access to the contacts list.
It looks like we do have a qr code implementation in-tree nowadays => https://searchfox.org/mozilla-central/source/devtools/shared/qrcode
Shouldn't we try to switch to this? Although this is in JS vs the existing code is in Java... and moreover Fenix might do it differently too.