When a Hybrid App Button Does Nothing

A mobile user taps a button. Nothing opens. There is no validation message, exception, or visible loading state. The control simply appears dead. These bugs are frustrating because the visible symptom is tiny while the real interaction crosses several technical boundaries. I recently investigated this kind of failure in a Blazor Hybrid image workflow. The feature behaved sensibly in a desktop browser, but the same interaction did not reliably open the photo picker inside an iOS WebView. The useful lesson was broader than the eventual CSS change: A native capability launched from hybrid web UI is a cross-layer contract, not a single component event. To make the interaction dependable, the browser gesture, responsive dialog, native application metadata, and automated tests all had to agree.

The visible button was not the real control

Styled file-upload controls commonly hide the browser's native file input. A label or custom button receives the click and forwards it to the hidden input. That pattern can work well on desktop browsers. It provides visual freedom while retaining a native file-selection control underneath. The implementation I examined had taken the hiding quite far: the real input was clipped to a tiny area, while a separate visible element acted as its proxy. On desktop, the browser carried the user action through that indirection. Inside the iOS WebView, the picker did not open.

This matters because browsers deliberately protect privileged actions. File pickers, cameras, pop-ups, clipboards, and media playback often require a trusted user activation. The further the real privileged element is removed from the original tap, the more likely platform differences become visible.

The fix was conceptually simple: make the transparent file input span the visible button. The control still looks custom, but the user's tap now lands directly on the input that owns the privileged action. The input is visually transparent, not functionally absent.

One repaired layer was not enough

It would have been tempting to stop once the picker opened. The wider interaction still contained two other failure points.

First, the crop interface relied on default dialog sizing. On a phone viewport, the default width could produce a narrow, awkward workspace. A picker that opens successfully is not much help if the next interface is effectively unusable. Explicit mobile-appropriate dialog options made the intended behavior part of the call rather than an accidental consequence of a UI library's defaults.

Second, the picker offered access to native media sources. That brings the iOS application manifest into the contract. Applications must include understandable usage descriptions for protected capabilities such as the photo library and camera. Missing metadata is not a cosmetic omission. A user can complete the web portion of the interaction and then encounter a native failure when choosing a particular source.

The complete path therefore looked like this:

• A real user gesture reaches the browser file input.
• The WebView requests the platform picker.
• The native application has declared the relevant capability.
• The selected file returns to a dialog that fits the device.
• The application processes the result while preventing conflicting actions.

Each step belongs to a different layer, but the user experiences them as one button.

Tests also participate in the contract

The production change added explicit dialog options. That changed which overload of the dialog service was called. Existing component tests had mocked the previous overload. The tests then failed with a null reference-not because the new production behavior was wrong, but because the test double no longer described the real collaboration. Updating the mock restored coverage for the important component behavior:

• Processing an accepted image blocks conflicting actions.
• The local preview reflects the accepted result.
• Upload lifecycle notifications are raised in order.
• Cancelling the dialog produces no upload side effects.

Those tests are valuable, but they do not prove that an iOS picker will open. A component test can verify state transitions after a simulated dialog result. It cannot fully reproduce WebView gesture policies, native permission enforcement, or a real device viewport. That is an important testing boundary to acknowledge honestly.

A sensible test portfolio for this interaction includes fast component tests for application behavior, plus a small device-level smoke test for the native handoff. The device test does not need to cover every cropper feature. It only needs to prove that tapping the visible control opens the picker and that each offered media source reaches the expected permission path.

The trade-off

Putting a transparent native input over a custom control creates some styling and accessibility responsibilities. Its hit area, focus behavior, keyboard behavior, and disabled state must remain aligned with the visible UI. Native metadata also has to be maintained across application targets, while device testing adds cost beyond ordinary browser tests.

The alternative is worse: a polished control whose critical action depends on browser-specific forwarding behavior, or a picker that opens but fails when the user chooses a native source. The extra work buys a smaller compatibility gap and a clearer ownership model.

A practical review checklist

When hybrid UI launches a privileged native capability, I now ask:

• Does the real privileged element receive the user gesture?
• Is the next interface usable at the smallest supported viewport?
• Are all offered native capabilities declared?
• Do tests mock the exact production collaboration?
• Which part still requires validation on a real device?
• Does failure produce visible feedback instead of silence?

A "dead button" is often not one defect. It is a broken chain across layers. Following that chain from the user's finger to the native capability usually reveals both the immediate fix and the missing test boundary.