Bringing a desktop comic reader extension to Android: the interaction changes

NodeLane — Sun, 11 Oct 2026 03:12:32 +0000

A desktop comic reader can fit inside a phone viewport and still be awkward to use. Buttons may be technically visible but hard to hit, settings can cover the page, and a two-column comparison can make both versions unreadable.

I'm building NodeLane Comics, an open-source browser extension. It now has an Android Firefox entry point. This is a follow-up about the interaction decisions behind that work, rather than another product introduction.

1. A narrow window is not necessarily a phone

I wanted to keep the existing React components and reading workflow. A second mobile application tree would also mean a second place to maintain imports, translation state, and reading-position recovery.

The phone stylesheet is loaded after the desktop styles. Its outer gate combines a bounded device width with a coarse pointer or lack of hover:

@media (max-device-width: 1000px) and (pointer: coarse),
       (max-device-width: 1000px) and (hover: none) {
  @media (max-width: 700px),
         (max-width: 1000px) and (max-height: 500px) {
    .nc-app {
      --nc-phone-gutter: 12px;
      --nc-phone-gap: 8px;
      --nc-phone-hit: 44px;
    }
  }
}

This is the gate used by this project, not a universal device-detection recipe. The intention is to keep a narrow desktop window, a desktop extension popup, and a touch-enabled laptop from automatically receiving the full phone layout.

The compact landscape case matters too: a phone rotated sideways has more width, but very little height.

Implementation: phone.css

2. Touch targets need space; decoration can give some back

The mobile layout reduces panel padding and visual decoration without shrinking the controls people need to hit. Reader controls use 44px targets, and touch-oriented inputs keep a 16px minimum font size.

Navigation and page progress sit above the comic. Reading and translation controls sit below it. The directory and reading settings become full-screen drawers; translation settings use a bottom panel.

One small but important detail: hiding the controls should not change the comic's position. The reader keeps the relevant canvas space reserved, so bringing the controls back does not move the content underneath them. A tap can reveal tools; finger scrolling should not trigger desktop mouse-edge behavior.

This is less about making everything large and more about deciding what deserves the limited space.

3. Original/translation comparison should preserve readable text

On a desktop, two pages side by side are useful. On a narrow phone, squeezing each page into half the screen can defeat the point of comparison.

The narrow-screen layout preserves a readable page width and allows horizontal viewing instead. Switching back to the original remains available, and the existing reading-position restoration is retained.

I did not add a separate mobile translation workflow. The UI still consumes the same page-level results and failures. A layout change should not silently become a second implementation of task submission or recovery.

4. File import is a browser-and-OS interaction

The starting point remains a normal file input, not a custom imitation of the Android picker:

<input
  type="file"
  multiple
  accept={COMIC_ACCEPT}
  onChange={e => chooseFiles(Array.from(e.target.files ?? []))}
/>

This shortened excerpt shows the existing import path. The supported collection includes CBZ/ZIP, CBR/RAR, PDF, and DRM-free MOBI/EPUB; the extension is not a loose-image organizer.

For a first mobile check, a small known CBZ is more useful than a huge archive. It separates basic picker/import problems from memory pressure, parsing time, and unusually complex files.

Evidence boundary: this is an existing tutorial capture from Android 14 and Firefox 157.0.1, with a temporarily loaded Mozilla-signed 0.10.3 extension. The project's original sample was packaged as a one-page CBZ and imported through the real file picker. It illustrates the Android reading path, not the latest layout or verified permanent store installation, sign-in, or translation.

5. Missing desktop APIs must not prevent the reader from starting

Responsive CSS does not solve browser-extension compatibility.

Firefox Android may lack desktop capabilities such as commands, context menus, or separate browser windows. Initialization must tolerate those missing capabilities. For the Drive connection flow, the implementation can use a normal tab instead of requiring a separate window, while retaining the existing authorization message bridge.

The same principle applies to image handling: where OffscreenCanvas is unavailable, the extension has a native canvas fallback. That is a capability fallback, not permission to assume that authorization or processing succeeded.

A practical self-hosting detail belongs in the mobile instructions as well: localhost on a phone is the phone, not the computer running a translation service.

6. Keep resource use bounded, and name what a test proves

A comic reader can contain many large images. The mobile work keeps the existing bounded image window and virtualized shelf instead of rendering or decoding an entire library at once. The stylesheet does not add viewport polling or a second set of data requests.

I do not have a before/after device performance benchmark to claim here. Preserving those limits is a design constraint, not proof that every phone will handle a large PDF equally well.

There are also several different kinds of validation:

A narrow-screen browser test can check layout, target sizes, and position restoration.
An Android emulator can exercise the actual browser and file picker.
A physical device is still needed to check its installation path, keyboard, background behavior, authorization callbacks, and real reading workload.

Those should not be collapsed into a single “mobile works” checkbox. iOS / Orion remains compatibility work in progress, not a supported platform announcement.

Try the reading path

The Android Firefox guide has the official extension listing and setup steps. This is a Firefox extension, not a NodeLane APK, and the store's compatibility checks still apply.

Reading local originals does not require a NodeLane account. Official translation is optional, needs sign-in and an internet connection, and is subject to the current allowance or paid plan. A self-hosted translation service is another option.

For feedback, I'm especially interested in three concrete things: which file format failed to import, which control was hard to reach, and whether opening settings or switching page versions moved the reading position.

What desktop interaction did you have to rethink most when bringing an existing web app to touch screens?

AI assisted the English drafting of this article. The implementation details were checked against the project code and documentation; unverified device and service behavior is called out above.

I built an open-source manga reader + translator browser extension

NodeLane — Sat, 26 Sep 2026 13:46:35 +0000

Android update — October 11, 2026: NodeLane Comics can now be used in Firefox for Android. You can import your own comic files, read with touch controls, and switch between originals and translations. Start with the Android Firefox installation and reading guide and the Firefox Add-ons listing. This is an extension, not a standalone Android app; iOS / Orion compatibility is still in progress. Local original reading needs no NodeLane account. Official translation requires sign-in, connectivity, and an available allowance. The guide labels its emulator screenshots and their verification limits.

Hey DEV! I’m building NodeLane Comics, a manga reader and translator that runs as a browser extension.

The idea is to bring manga from different places into one library: supported websites, local files, and Google Drive. Translation is optional — you can just use it as a reader.

What it does

Keep your manga in one place. Import from supported websites, Google Drive, or local files such as CBZ, CBR, PDF, and DRM-free MOBI.
Keep track of your reading. Save your progress and check for new chapters from supported websites.
Translate as you read. Use a cloud translation service or connect a local manga-translator-ui instance, then switch between the original and translated pages.
Translate inside a browser tab. Display translated manga images directly on supported pages without importing the comic into the reader.

There’s also a cross-language title search to help you look for the same comic on selected websites in another language.

A little about the build

The extension uses TypeScript, React, and WXT, with a FastAPI backend. Both the frontend and backend code are public on GitHub.

Local translation connects to a separately running manga-translator-ui service — the extension itself doesn’t run the translation models.

Looking for feedback

It’s still early. I’m working on supporting more websites and improving stability, especially around translation.

Right now, I’m looking for people to try it with their usual reading setup and tell me what feels useful, confusing, or missing. Feedback on the reader itself is just as welcome as feedback on translation.

Try the Chrome extension

View the code on GitHub

Do you mostly read manga on websites, from local files, or a mix of both? I’d love to hear how you currently keep everything organized.

I used AI to help draft the English text for this post.

DEV Community: NodeLane