Closed Bug 1938868 Opened 2 months ago Closed 2 months ago

Address bar QR-code scanner button doesn't work; goes to black screen saying "No camera available on device"

Categories

(Fenix :: QR, defect)

All
Android
defect

Tracking

(firefox133 unaffected, firefox134 unaffected, firefox135+ verified)

VERIFIED FIXED
135 Branch
Tracking Status
firefox133 --- unaffected
firefox134 --- unaffected
firefox135 + verified

People

(Reporter: dholbert, Assigned: royang)

References

(Regression)

Details

(Keywords: regression)

Steps to reproduce

  1. Tap the address bar.
  2. Tap the QR-code-scanner button at the right side of address bar.

Expected behavior

QR code scanner opens.

Actual behavior

Black screen, "No camera available on device"

Device information

  • Firefox version: Nightly 135.0a1 2024-12-19
  • Android device model: Pixel 6a, Pixel 8
  • Android OS version: Android 15

Any additional information?

This is a recent regression. With mozregression, I determined Nightly 2024-12-17 is "last good" and Nightly "2024-12-18" is "first bad". Using the hg revisions from "About Firefox" UI in those builds, I got this regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=10fe3e4fee81&tochange=af703e4a9001

Not sure what in there might be most-related; royang, maybe you have some ideas?

[Tracking Requested - why for this release]: pretty substantial functional regression; can't scan QR codes in Firefox anymore.

Flags: needinfo?(royang)

(BTW, I checked Android's "app info" UI for Firefox Nightly, and I do see that "Camera" is in the "Allowed" section. So we do theoretically have camera access.)

(In reply to Daniel Holbert [:dholbert] from comment #0)

Not sure what in there might be most-related; royang, maybe you have some ideas?

I wonder if this might have been "Bug 1938090 - Stop pinning the Android SDK platform-tools"? Just from the name at least, it sounds conceivable that a "platform-tools" version-change might be the sort of thing that could impact our ability to interface with hardware capabilities like the camera.

Anything is possible, I suppose, but those are just the tools used for creating the builds and running tests (adb, fastboot, etc). They shouldn't directly impact the binaries we ship to end users.
https://developer.android.com/tools/releases/platform-tools

Does this reproduce in an emulator by chance? Might be easier to bisect with autoland builds there.

clues from logcat, filtered for "camera" (case-insensitive), the first time I open the camera, comparing bad/good nightlies (after/before the regression range):

In a "bad" Nightly, logcat just shows this and no mentions of "camera" afterwards:

I CameraManagerGlobal: Connecting to camera service

In a "good" Nightly, logcat shows much more, starting with:

I CameraManagerGlobal: Connecting to camera service
D Camera3-Utils: Set real time priority for thread (tid 1077)
I CameraService: CameraService::connect call (PID 13444 "org.mozilla.fenix", camera ID 0) and Camera API version 2
I Camera2ClientBase: Camera 0: Opened. Client: org.mozilla.fenix (PID 13444, UID 10414)
I CameraDeviceClient: CameraDeviceClient 0: Opened

Searching our codebase for CameraManager, for potentially-related files, I found
https://searchfox.org/mozilla-central/rev/21710237a214fdb72d0799c297da4fb9b60ccff9/mobile/android/android-components/components/feature/qr/src/main/java/mozilla/components/feature/qr/CameraManager.kt#8
...which was added in Bug 1927695. I don't think that bug was directly related to this regression (it landed over a month earlier), but it does mention that we check for SDK-version-specific camera-features, which superficially at least lends credence to blaming a commit that has "SDK" in the commit message. :)

Component: Toolbar → QR
Assignee: nobody → royang
Flags: needinfo?(royang)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #3)

Anything is possible, I suppose, but those are just the tools used for creating the builds and running tests (adb, fastboot, etc). They shouldn't directly impact the binaries we ship to end users.
https://developer.android.com/tools/releases/platform-tools

Shot in the dark, I wonder if it impacts some build-time check for how-to-talk-to-the-camera... (the equivalent of some #ifdef in C++ code)

There are very few Android/fenix commits in the regression pushlog, so I don't have any better theories at a regressor right now.

Does this reproduce in an emulator by chance? Might be easier to bisect with autoland builds there.

I don't have a fenix build environment right now, so I'm not sure. I did test gve (installed via mozregression) but unfortunately we don't show this button there.

[Aha, midair'ed with royang while typing this - I see he's self-assigned this, thanks royang!]

Severity: -- → S2
Regressed by: 1938824

Found the issue was caused by Bug 1938824 which is getting a fix and it has landed.

The fix works locally but I'll wait till the next Nightly to confirm.

Thanks!

No longer regressed by: 1938824
See Also: → 1938824
Regressed by: 1919488

Confirmed fixed for me by side-loading today's Nightly apk (build #2016063778) onto my Pixel 7. Will get it submitted for Play Store review as soon as possible.

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 135 Branch

Confirmed issue fixed in latest Nightly

Fixed for me in my up-to-date Nightly from play store (datestamp 2024-12-25), too. Thanks!

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.