1984694 - Emoji domains (IDN with Unicode emojis) don’t resolve in Firefox for Android address bar

Status: UNCONFIRMED

(Firefox for Android :: Toolbar, enhancement)

Description

[peter]

Attachment: Technical Feature Request.pdf

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36

Steps to reproduce:

1 - Open Firefox for Android

2 - In the address bar, type: 🏀.to (basketball emoji + .to).

3 - Hit enter to load the page.

Actual results:

Instead of resolving the domain, Firefox performs a web search for “🏀.to” (even if “https://” is typed before it).

Expected results:

Firefox should correctly resolve the emoji domain via its punycode equivalent (xn--xl8h.to) and load the destination page, just like Chrome or Safari do.

Comment 1

[peter]

This issue matters because emoji domains are valid IDNs (Internationalized Domain Names) already supported by Chrome, Safari, and most modern browsers. On mobile, emojis are part of the native keyboard and widely used (6B+ emojis sent daily). For brands (Nike, Coca-Cola, etc.) and users, this represents both a usability and accessibility expectation. The lack of support in Firefox creates inconsistency and friction compared to other browsers.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox for Android::Toolbar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[peter]

Additional context on emoji domains and user expectations

Thanks for looking into this. Just to add some perspective from a UX and standards point of view:

Emoji domains are valid IDNs (Internationalized Domain Names), already supported in Chrome, Safari, and even Firefox desktop. The fact that Firefox desktop resolves them but Firefox Android does not creates an inconsistent experience across platforms.

Mobile-first context: Over 95% of global internet usage growth is happening on mobile. In India, for example, ~98% of internet access is already mobile. On mobile devices, emojis are built directly into the keyboard, arguably more universal than any specific written language.

Adoption by major brands: Nike has used 🏀.to to redirect to its basketball page since 2017, and Coca-Cola ran an emoji domain campaign in Puerto Rico that went viral, generating millions in earned media from a $3,000 spend. These are not just theoretical cases, but real-world usage.

User behavior: Roughly 6 billion emojis are sent every day across platforms. For users, typing or recognizing an emoji is a native, low-friction action. When a browser doesn’t resolve them, it feels like an inconsistency rather than a technical limitation.

Security concerns: Punycode and Unicode handling are already part of the IDN standard. Other browsers display the emoji glyph (instead of the punycode) without additional risk. If the concern is phishing, that’s a broader IDN issue, not unique to emojis.

Expected behavior: Firefox for Android should recognize emoji domains (via Punycode) in the address bar the same way Firefox desktop, Chrome, and Safari already do.

This would align with existing IDN standards, remove friction for users, and ensure Firefox remains competitive in supporting emerging UX patterns on mobile.

Comment 4

[Elijah]

so the rationale here is wrong, emoji domains are explicitly not allowed per RFC 5892. what you're asking is to subvert that which might not be a bad idea if other mobile browsers are already doing it, tho that's not a good reason why Firefox should do it lol

anyway the fix here is simple, just change the RegEx at isURLLenient() or convert to Punycode before receiving the URL. but tbh I want to get more info on if this is something worth changing

Comment 5

[peter]

Thanks Elijah, appreciate the quick triage.

Context / spec: You’re right re: RFC 5892; emojis aren’t permitted in IDNA2008, which is why ICANN SSAC discourages them. That said, several registries (e.g. .to, .ws) do delegate emoji labels today, and both Chrome (Android) and Safari (iOS/macOS) successfully resolve these domains by converting the typed emoji to Punycode on navigation (Chrome typically displays Punycode in the Omnibox for safety; Safari often renders the emoji glyph).

Problem statement (Android only): On Firefox for Android, typing 🏀.to in the URL bar currently triggers a search instead of attempting navigation. On Firefox Desktop, navigation works (Punycode path). This is primarily a UX consistency gap: users expect “try navigation first, then search,” especially when other major browsers resolve it.

Proposed minimal change:

In the URL bar pipeline, when input contains non-ASCII and would otherwise be sent to search, attempt an IDNA/Punycode conversion first.

If conversion yields a syntactically valid hostname (e.g. xn--xl8h.to) → navigate.

If conversion fails → fallback to search (current behavior).

Concretely, doing the conversion earlier (before the “is this a URL?” decision) would let isURLLenient() see a valid ASCII hostname. (As you noted, adjusting the regex or pre-converting would both work; pre-conversion seems cleaner and safer long-term.)

Security considerations:

This doesn’t broaden Unicode acceptance beyond what DNS already serves; it just prevents a false negative that routes to search.

Chrome’s model (resolve but display Punycode) is a reasonable default to avoid lookalike risks; Firefox could do the same on Android.

If desired, gate this behind Nightly or a pref initially and collect telemetry (rate of successful conversions/navigations vs fallbacks).

Repro cases:

🏀.to → xn--xl8h.to

🍕.ws (common example on Safari/Chrome)

Expected result: Consistent with Firefox Desktop and with Chrome/Safari: typing an emoji domain navigates (showing Punycode in the bar), not a web search.

Happy to provide additional test cases, logs, or record a quick screencast on Android if that helps.