av9ash/GitBugs huggingface dataset:
Bug: Copy/save screenshot shortcuts (Ctrl+C, Ctrl+S) don't work with (non-English) Russian keyboard layout
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-10 00:44:03+00:00
Resolved: 2025-02-04 23:18:46+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

1. Select a region for a screenshot
2. If Windows keyboard input is non-English (Russian in my case), Ctrl+C and Ctrl+S won't work
3. Shortcuts work after switching input language to English
Bug: HTTP Authentication Spoof on Firefox for IOS & Android
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-10 03:51:30+00:00
Resolved: 2025-01-20 12:38:54+00:00

## Summary & Details
This vulnerability occurs when there is a condition that Browser HTTP Authentication can be spoof. This means that the omnibox will show paypal.com for example, while the omnibox still shows paypal.com, the HTTP authentication prompt from https://eviltrap.site will appear.

## Steps to Reproduce
1. Access the PoC page using Firefox for IOS & Android (https://frozzipies.github.io/httpauthspoof.html)
2. Press the button
3. You will see that the URL omnibox will show paypal.com and the HTTP Authentication Pop Up that come from https://eviltrap.stie will appear when the omnibox still on paypal.com

I've attach PoC, Source Code, etc here:
https://drive.google.com/drive/folders/1AkQv0YXYTUMr3_Y2S1bGQzQtAHFxCPIy?usp=sharing

Similar issue references:
https://issues.chromium.org/issues/40055876
Bug: Source title's color in DS sections is an inaccessible color when high contrast and light theme are toggled
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2025-01-10 04:14:22+00:00
Resolved: 2025-01-13 09:38:21+00:00

Seems that if users have a setting of **preferred contrast** on their devices + they have light-theme toggled, the source titles of content cards are a white color instead of black.

On mac, enable the preferred contrast setting by:
- Going to settings
- Selecting 'Accessibility'
- Selecting 'Display'
- Toggling on 'Increase contrast'


Steps to reproduce:
1. Open a new tab page on Firefox
2. Click the devtools icon (if disabled, go to `about:config` and enable the `browser.newtabpage.activity-stream.asrouter.devtoolsEnabled` pref)
3. Enable the DS Sections toggle
4. Open a new tab
5. If light theme is toggled, notice the source title of the content cards is a white color on a white background, making it inaccessible.

Expected result:
Source title is an accessible color (i.e. black)

Actual result: 
Source title's color is white on a white background, deeming it inaccessible
Bug: Permission toast message is displayed behind the address bar when using a dark theme
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-01-10 07:36:00+00:00
Resolved: 2025-01-20 12:40:02+00:00

@ Emilio, I bisected this regression to this pushlog for your address bar bug 1927111:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=13537ae67079d33202b6570bb5a61d4ee652fecb&tochange=aa2b4302bdccdbfd659158479d68c4f377237e6c

### Steps to reproduce

1. Open `about:addons`
2. Enable a non-default theme, such as the "Firefox Alpenglow" theme.
2. Open https://permission.site/
3. Scroll down and click the "Pointer Lock" button.

### Expected result

The "permission.site has control of your pointer." toast message is displayed in front of the address bar.

### Actual result

The "permission.site has control of your pointer." toast message is displayed _behind_ the address bar. See the attached screenshot.
Bug: Add-ons Manager with unnecessary scrollbar
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-01-10 08:38:11+00:00
Resolved: 2025-01-27 13:43:42+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

Open Settings -> Extensions & Themes -> Extensions


Actual results:

Unnecessary scrollbars appeared


Expected results:

It should be clean without scrollbar
Bug: The IAB Banner is automatically removed after dismissing all the Pocket stories
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2025-01-10 14:07:23+00:00
Resolved: 2025-01-22 22:49:34+00:00

**[Affected versions]:**
- Firefox Beta 135.0b2 (Build ID: 20250108092002)
- Firefox Nightly 136.0a1 (Build ID: 20250110094927)

**[Affected Platforms]:**
- Windows 10 x64
- Ubuntu 24.04 x64
- macOS 14.7.1

**[Prerequisites]:**
- Have a Firefox Beta 135.0b2 "en-US" locale build installed.
- Follow the instructions from this TestRail [test case](https://mozilla.testrail.io/index.php?/cases/view/2838094&group_by=cases:section_id&group_order=asc&display_deleted_cases=0&group_id=565085) in order to trigger an IAB banner.

**[Steps to reproduce]:**
1. Open a new tab and make sure an IAB Banner is displayed.
2. Dismiss all of the Pocket stories from the “Thought-provoking stories” section.
3. Observe the behavior.

**[Expected result]:**
-  The IAB Banner remains displayed since it wasn’t specifically dismissed by the user.

**[Actual result]:**
-  The IAB Banner is automatically dismissed.

**[Notes]:**
- This issue is reproducible with both the Billboard and Leaderboard IAB Banners.
- Attached is a screen recording of the issue.
Bug: [Experiment] The “browser.urlbar.weather.minKeywordLength” pref is not working
Status: VERIFIED
Priority: --
Resolution: INVALID
Created: 2025-01-10 15:39:28+00:00
Resolved: 2025-01-13 08:24:44+00:00

**[Notes:]**
- In the experiment recipe, the urlbar value is  "weatherKeywordsMinimumLength": 3, but this doesn't work for any keywords. (e.g: temperature, weather, cloudy)



**[Affected versions]:**
- Firefox Beta 135.0b2 - Build ID: 20250108092002 (changed channel in Release)


**[Affected Platforms]:**
- Windows 11 x64
- macOS Sequoia 15.0.1
- Ubuntu 22.04 x64


**[Prerequisites]:**
- Have a user.js for any branch (except Control) to enroll into the experiment.

**[Steps to reproduce]:**
1. Open the browser from the prerequisites.
2. Navigate to “about:support” and search for “Profile Folder”.
3. Click on “Open Folder” from the “Profile Folder”.
4. Copy the user.js from the prerequisites into the selected profile.
5. Restart the browser and notice that the user is enrolled into the experiment.
6. Open a new tab and open the address bar.
7. Type in the address bar minimum 3 characters from a keyword which will trigger a weather result. (e.g: “wea”)


**[Expected result]:**
-  The weather result is triggered if the user is typing a minimum 3 characters from an appropriate keyword.

**[Actual result]:**
-  The weather result is not triggered if the user is typing only 3 characters from an appropriate keyword; the user should type the whole keyword for weather suggest to appear


**[Additional Notes]:**
- A video of this issue is attached.
Bug: Timestamp and a three dot menu are not displayed for items under "Tabs from other devices" in Firefox View Next tab
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2025-01-10 15:40:58+00:00
Resolved: 2025-02-04 15:11:52+00:00

**Found in**
* Firefox 135.0b2 

**Affected versions**
*  Nightly 136.0a1
*  Beta 135.0b2
*  Release 134.0

**Tested platforms**
* Affected platforms: Windows 11, macOS 15, Ubuntu 24.04
* Unaffected platforms: -

**Preconditions**
* Have Firefox with few tabs opened
* Make sure FxA account  connected to other desktop devices

**Steps to reproduce**
1. Open Firefox View Next tab
2. Under the Recent Browsing section, check Tabs from other devices section.

**Expected result**
* Tabs from other devices card should be displayed and every item in the list should have title, domain, timestamp and a three dot menu

**Actual result**
* Tabs from other devices card is displayed but items in the list do NOT have  have timestamp and a three dot menu

**Regression range**
* Looking for it as soon as possible

**Additional notes**
* Same issue is reproducible under the Tabs from other device section from the Firefox View page.
* On Release 134.0 only the timestamps are not visible.
Bug: New search bar still defaults to Google after changing the order of the search engines
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2025-01-10 19:44:37+00:00
Resolved: 2025-01-13 15:36:44+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

I changed the order of the search engines to default to DuckDuckGo first but Google is still the default in the new search bar.


Actual results:

Google is the default in the new search bar


Expected results:

DuckDuckGo should be the default
Bug: Contextual Search Mode ignores text input if there is a saved search engine
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2025-01-11 12:25:12+00:00
Resolved: 2025-01-22 10:03:02+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

1. Save Wikipedia to Firefox search engines
2. Open https://en.wikipedia.org/
3. Focus the address bar
4. Enter a search query
5. Click "Search with Wikipedia" (Contextual Search Mode button)


Actual results:

A clear address bar is displayed with the Wikipedia search engine chosen. User's query is removed.


Expected results:

Search results should be displayed for user query. 

But this only happens on those sites if their search engines have not been saved to Firefox’s search engine list

Video:
https://drive.proton.me/urls/FVJ152BCTR#VZdNTo4SQ6Vd
Bug: Auto logout when I turn of the pc
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-01-11 12:46:53+00:00
Resolved: 2025-01-12 16:27:12+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

After the most recent update of Firefox it started to require me to login in my Mozilla account every time I turn on the pc and use the browser



Expected results:

Stayed login on the account
Bug: Latest update broke navigation bar recent button from working with Firefox
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-11 15:22:50+00:00
Resolved: 2025-01-11 15:35:35+00:00

User Agent: Mozilla/5.0 (Android 14; Mobile; rv:134.0) Gecko/134.0 Firefox/134.0
Firefox for Android

Steps to reproduce:

Tried to use nav bar on phone to show tab history in Firefox like I always have and it no longer works. 


Actual results:

Nothing. No longer allows recent button in nav bar of phone to show tab history. 


Expected results:

Recent button on phone should of showed tabs history just like back button in Firefox's menu when you do a press hold.
Bug: Since version 134.0 (maybe some earlier) commandline key "/launchbrowser=0" stopped working.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-01-11 15:39:42+00:00
Resolved: 2025-01-13 16:46:12+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

"Firefox Installer.exe" /silent /launchbrowser=0


Actual results:

Firefox started after installation/


Expected results:

It must not start (as  required by "/launchbrowser=0" command line key)
Bug: Vertical tab spacing changes when the vertical tab bar is collapsed/expanded
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2025-01-12 09:01:21+00:00
Resolved: 2025-01-25 21:18:20+00:00

STR:
1. Enable Vertical tabs
2. Open several tabs
3. Toggle collapse/expand vertical tabbar

AR:
Vertical tab spacing changes when the vertical tab bar is collapsed/expanded.
Screencast: https://youtu.be/wX9ra1KLst4

ER:
Vertical tab spacing should not change

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c72899901f29c51caa57cb3b84518041a9952e18&tochange=3b597e62bd28015328688468f817ad50d4d42106
Bug: Firefox Sync cannot be signed into
Status: RESOLVED
Priority: --
Resolution: INACTIVE
Created: 2025-01-12 10:49:42+00:00
Resolved: 2025-02-10 20:45:32+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

Try to sign into Firefox sync with 2 factor authentication


Actual results:

No error, completes, does not initiate any syncing behavior, browser stays completely inert with no change. Multiple attempts to sign in result in the same exact "no error, no behavior" response. Just nothing.


Expected results:

Profile picture populates, syncing behavior initiates, extensions install, sync is completed.
Bug: Perma browser/components/sidebar/tests/browser/browser_sidebar_collapsed_close_tab_button.js | The inactive tab is not showing the close button. - Got "1", expected "0" when Gecko 136 merges to beta on 2025-02-03
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2025-01-12 10:55:39+00:00
Resolved: 2025-01-27 06:55:06+00:00

[Central as beta simulation](https://treeherder.mozilla.org/jobs?repo=try&resultStatus=testfailed%2Cbusted%2Cexception%2Crunnable&revision=c15b7e49750e88ab567650ff4f73f6cbf61ebf7e&selectedTaskRun=KnRghSiOTqG0FrYZTpVDww.0&searchStr=Linux%2C18.04%2Cx64%2CWebRender%2Cdebug%2CMochitests%2Cwith%2Csoftware%2Cwebrender%2Cenabled%2Ctest-linux1804-64-qr%2Fdebug-mochitest-browser-chrome-swr%2Cbc11)

[How to run these simulations](https://wiki.mozilla.org/Sheriffing/How_To/Beta_simulations#TRUNK_AS_EARLY_BETA)

[Failure log](https://treeherder.mozilla.org/logviewer?job_id=489773073&repo=try&lineNumber=20331)

```
TEST-PASS | browser/components/sidebar/tests/browser/browser_sidebar_collapsed_close_tab_button.js | The active tab is showing the close button. - 
[task 2025-01-12T10:38:25.141Z] 10:38:25     INFO - Buffered messages finished
[task 2025-01-12T10:38:25.141Z] 10:38:25     INFO - TEST-UNEXPECTED-FAIL | browser/components/sidebar/tests/browser/browser_sidebar_collapsed_close_tab_button.js | The inactive tab is not showing the close button. - Got "1", expected "0"
[task 2025-01-12T10:38:25.142Z] 10:38:25     INFO - Stack trace:
[task 2025-01-12T10:38:25.142Z] 10:38:25     INFO - chrome://mochikit/content/browser-test.js:test_is:1627
[task 2025-01-12T10:38:25.142Z] 10:38:25     INFO - chrome://mochitests/content/browser/browser/components/sidebar/tests/browser/browser_sidebar_collapsed_close_tab_button.js:test_toggle_collapse_close_button:43
[task 2025-01-12T10:38:25.142Z] 10:38:25     INFO - chrome://mochikit/content/browser-test.js:handleTask:1147
[task 2025-01-12T10:38:25.142Z] 10:38:25     INFO - chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1219
[task 2025-01-12T10:38:25.142Z] 10:38:25     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1360
[task 2025-01-12T10:38:25.142Z] 10:38:25     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:1136
[task 2025-01-12T10:38:25.142Z] 10:38:25     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1058
[task 2025-01-12T10:38:25.142Z] 10:38:25     INFO - TEST-PASS | browser/components/sidebar/tests/browser/browser_sidebar_collapsed_close_tab_button.js | The inactive tab is showing the close button on hover. 
```
Bug: right mouse button opens very long context menu where nothing works
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-12 13:22:44+00:00
Resolved: 2025-01-13 06:44:05+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

Upgraded on Fedora 41 Firefox 133.0.3-2.fc41.x86_64 -> 134.0-1.fc41.x86_64.
This is a regression.
Unfortnuately it is not reproducible in a new profile. Not even when I transfer "prefs.js".



Actual results:

On some links / some webs (not everywhere) right mouse button opens very long context menu with all possibilities but moreover none of them works.


Expected results:

Normal short context menu with "Open Link in New Tab" etc.
Bug: URL bar history no longer works in 134
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-12 13:35:17+00:00
Resolved: 2025-01-13 06:44:05+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

Upgraded on Fedora 41 Firefox 133.0.3-2.fc41.x86_64 -> 134.0-1.fc41.x86_64.
This is a regression.
I am not sure if it is reproducible in a new profile a the URL bar behaves weirdly by default. I have it probably somehow configured disabling search services, just showing history of my browsing.


Actual results:

No historical data is shown in firefox-134.0-1.fc41.x86_64.


Expected results:

Historical data were shown in firefox-133.0.3-2.fc41.x86_64.
Bug: Firefox does not display SVG correctly
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-12 14:09:36+00:00
Resolved: 2025-01-12 14:36:31+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

SVG Files on this page 
https://50ohm.de/N_wasserfall.html
are not displayed at all. 
Here is a link to one SVG directly. 
https://50ohm.de/img/picture_578.svg

Tested on Firefox 134 on Linux and Android.


Actual results:

The SVG should be displayed. 
On attached screenshot left is firefox, right is chrome. 
Chrome and Brave display the SVGs correctly. 


Expected results:

SVG should be displayed.
Bug: DNS resolution crashed or something
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-12 16:20:26+00:00
Resolved: 2025-01-12 16:38:29+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:136.0) Gecko/20100101 Firefox/136.0

Steps to reproduce:

- Use Firefox 136.0a1 (2025-01-12) (64-bit) on macOS
- Try to browse on the internet
- At some point, something crashes internally and any tab does not respond anymore in a network way


Actual results:

Feel like the DNS resolution inside Firefox has crashed or something.


Expected results:

Should work.
Bug: PDF Viewer text annotation Hebrew characters are not rendered in some viewers
Status: UNCONFIRMED
Priority: --
Created: 2025-01-12 20:30:42+00:00
Resolved: 2025-02-19 13:37:09+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

1. Add text annotation to PDF using Hebrew characters
2. Save the PDF.
3. Open the PDF in GIMP or PDF Arranger.
4. Notice missing Hebrew characters.

BUT!!!!
5. Print the same file to PDF (in firefox).
6. Open the printed PDF in same programs.
7. The Hebrew characters are visible.

There must be a change in the way the PDF is saved by the viewer and the way PDF is saved by the print.



Actual results:

Hebrew characters are not displayed, probably font mapping issue?
This common to GTK?
Other viewers shows the PDF correctly.


Expected results:

Show Hebrew characters correctly.
Bug: Follow/unfollow UI in cards sections are inaccessible with a dark background
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2025-01-13 03:58:26+00:00
Resolved: 2025-01-15 07:35:10+00:00

Make sure to have the following prefs enabled to view the Follow/Unfollow button UI: 
- `browser.newtabpage.activity-stream.discoverystream.sections.personalization.enabled`
- `browser.newtabpage.activity-stream.discoverystream.sections.cards.enabled`
- `browser.newtabpage.activity-stream.discoverystream.sections.enabled`

If a user has a dark background set on their about:home page, the follow/unfollow buttons are not easily seen compared to light backgrounds.
Bug: Action search behavior deviates from other special searches
Status: NEW
Priority: P3
Created: 2025-01-13 09:29:39+00:00
Resolved: 2025-01-27 16:32:17+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

1. Focus on the address bar.
2. Type > to start the action search.
3. Type query, "print" for example.



Actual results:

Default search is activated. To initiate action search, the user must press the spacebar after the ">" keyword.



Expected results:

Action search is activated, and the "print" button is displayed. This is expected behavior, as it occurs with other keyword.

In summary:
- Bookmark search (*) and tab search (%) do not require a space after the key symbol.
- Action search does require a space after the key symbol.

Particularly noteworthy is that if the user input is simply « print » without the keyword « > », they will encounter a secondary action button. However, this is not the case when keywords are used.
Bug: Saving an edited local PDF requires reselecting the Path
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-13 12:34:20+00:00
Resolved: 2025-01-28 12:54:15+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

- open a local PDF
- edit it (eg. highlight)
- hit "save"


Actual results:

A popup opens, where a file location is to be selected (behavior one would expect from a "save as" function instead of "save".
The path where the last PDF file was saved is the default, not the location of the current PDF.



Expected results:

The file should have been updated in its current location.
Bug: iFrames broken in FF 134 and above
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-01-13 13:05:32+00:00
Resolved: 2025-01-13 14:44:37+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

Following update to Firefox 134, locally generated iframe doesn't allow to switch between pages
Reproduced on 2 machines (Manjaro and Ubuntu 24.04) from different people on FF 134, also reproduced on 135 and 136 via Ubuntu snap
Script to generate said data was functional for a few years. Provided a simple example which is a cut down version of my original tool.

Script to generate said data was functional for several years and still works on Chrome and Chromium. Provided a simple example which is a cut down version of my original tool (broken_iframe_ff134.tgz)

Also reviewed the debug console but it's not showing anything of interest


Actual results:

index.html attached open with the iframe as expected:
firefox wrapper/index.html
However, unable to browse to the generated links within the iframe since update to 134.


Expected results:

Same behaviour as in 133 and below. Namely having the ability to browse between the links.
Note that "Open in a new tab" does load the pages wanted
Bug: Closing Settings does not go back to last tab when Settings already open
Status: NEW
Priority: P5
Created: 2025-01-13 13:14:17+00:00
Resolved: 2025-02-26 06:35:24+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

While the "Settings" tab was already open somewhere else, do

1. Click on "Settings" from the menu
2. Close the "Settings" tab


Actual results:

The focus did not go back to the tab from where I clicked on "Settings"


Expected results:

The focus went back to the tab from where I clicked "Settings"
Bug: Firefox Address Bar does not encode the space automatically when searching for the URL but does encode it when copying from the address bar.
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2025-01-13 13:22:09+00:00
Resolved: 2025-01-13 14:08:35+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

Search in the URL "https://indianexpress.com/" 
Try appending the URL address as "/indian mata" (with space) (Ex. "https://indianexpress.com/indian mata")




Actual results:

This was the URL displayed: https://indianexpress.com/indian mata


Firefox does not encode the space automatically when searching for the URL but does encode it when copying from the address bar.


Expected results:

Firefox should ideally either:
   - Encode the space to %20 in the address bar when searching (just like Chrome), or
    - At least show the URL as %20 when the user searches for it and not just when copying.

https://indianexpress.com/%indian%20mata