av9ash/GitBugs huggingface dataset:
Bug: location bar should contain url being resolved, even when not yet fetched
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-28 19:08:25+00:00
Resolved: 2024-08-29 09:17:24+00:00

This may be a bit subtle, but it seems obvious. There are times when a window is opened and the page attempts to connect to a url and the url is not yet visible in the location bar. I am not sure how to specify when this occurs, right now. But I have seen it many times.

Then, at times, the page cannot be fetched. At this point, the url I was trying to connect to is not visible in the location bar. If it was able to connect, then the location would have gone in. But now I cannot connect, and I am not even necessarily sure of that url I was trying to connect it. I do not see it now. I may know what I thought it was, but am I right?

If a page or tab is opened and the page attempts to connect to a url, why would the url go into the location bar first? I suggest that this would make the most sense and is not what is happening now.
Bug: [Nightly] white border under address bar
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-29 03:43:53+00:00
Resolved: 2024-09-11 15:54:16+00:00

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

Steps to reproduce:

Open a new Tab, when in dark-theme or open a dark-themed website
Nightly 131.0a1 (2024-08-28) (64-bit) on Windows 11. System theme is "dark". Nightly setup to follow system-theme.


Actual results:

Displays a white border below the address / url bar


Expected results:

maybe the white border should not be there?
Bug: New Tab shortcuts missing after Firefox update
Status: UNCONFIRMED
Priority: P3
Created: 2024-08-29 04:38:45+00:00
Resolved: 2024-10-24 13:33:56+00:00

Steps to reproduce:

Some users who had several pinned New Tab shortcuts are reporting that they are gone after updating to  Firefox 129:

* https://old.reddit.com/r/firefox/comments/1f3mq0d/
* https://old.reddit.com/r/firefox/comments/1eys7fl/

Please investigate this issue. I'm not affected by it.
Bug: Firefox DLP scans the pasted content multiple times in Google/OneDrive Documents (no agent running)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-29 06:05:47+00:00
Resolved: 2024-09-13 03:00:23+00:00

**Found in**
* 131.0a1 (2024-08-28)

**Affected versions**
* 131.0a1 
* 130.0-RC1
* 128.2.0esr

**Preconditions**
* Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view 
* Create a distribution folder inside the Firefox folder and paste the policies-2.json to it and then rename it to policies.json

**Tested platforms**
* Affected platforms: Windows 10/11
* Unaffected platforms: Ubuntu, macOS 

**Steps to reproduce**
1. Go to https://drive.google.com/drive/home and sign in
2. Open up a document in an external program (for example Notepad) and type “ok text” into it and copy it (or copy any text from a random website)
3. Go back to Google Drive and open any Google Docs/Sheets/Slides
4. Paste the copied text from step 2
3. Observe the behavior

**Expected result**
*  The pasted content is scanned only once

**Actual result**
*  The pasted content is scanned 2-3 times consecutively 

**Regression range**
* This is not a regression as this is a new feature

**Additional notes**
* Also reproducing for One Drive Documents (Word / PowerPoint / OneNote docs)
Bug: dark mode must apply everywhere
Status: RESOLVED
Priority: --
Resolution: MOVED
Created: 2024-08-29 08:18:59+00:00
Resolved: 2024-08-29 12:15:26+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36

Steps to reproduce:

enable dark mode and installed Dark Reader then went back to addons.mozilla.org 


Actual results:

got blasted with yet another white page. reached my limit and had to spend the rest of the day on narcotic pain meds to deal with migraine.


Expected results:

addons.mozilla.org should have been rendered with a dark background.
Bug: bottom-of-window URLs shown when hovering on a link don't percent-encode the same way as the addressbar
Status: NEW
Priority: --
Created: 2024-08-29 11:35:11+00:00
Resolved: 2024-09-03 17:57:23+00:00

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

Steps to reproduce:

Was reading https://embracethered.com/blog/posts/2024/m365-copilot-prompt-injection-tool-invocation-and-data-exfil-using-ascii-smuggling/ and got to the section titled "An Example Link With Hidden Data". When I hover over the link in Firefox, it doesn't render the trailing Unicode characters.


Actual results:

The status bar only shows https://wuzzi.net/ instead of https://wuzzi.net/%F3%A0%81%94%F3%A0%81%B2%F3%A0%81%B5%F3%A0%81%B3%F3%A0%81%B4%F3%A0%81%8E%F3%A0%81%AF%F3%A0%81%81%F3%A0%81%89


Expected results:

The status bar should show the full URL and not drop the trailing Unicode characters.

Safari/Chrome both show the Unicode. I've attached a screenshot of safari.
Bug: Blank thumbnails are shown in tab hover previews of about:blank pages
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-08-29 15:28:53+00:00
Resolved: 2024-09-03 14:44:32+00:00

Tested on 131.0a1 (2024-08-28) BuildID 20240828213451.

Prerequisites:

1. `browser.newtabpage.enabled` is set to _false_.
2. `browser.startup.homepage` is set to _about:blank_.

STR:

1. Visit `about:blank`/`about:home`/`about:newtab`.
2. Press `Ctrl + T` to open another new tab.
3. Hover the cursor over the inactive `about:blank` tab.

Expected Behavior:

No thumbnail is shown for `about:blank` pages.


Actual Behavior:

A blank thumbnail is shown for `about:blank` pages, even though it offers literally zero additional information (not even scroll position).

Yes I have checked Chrome and they do this too. But why blindly copy whatever Chrome's doing at the moment at all?
Bug: Missing "Playing audio" indicator in tab hover previews
Status: NEW
Priority: P3
Created: 2024-08-29 15:35:37+00:00
Resolved: 2024-09-05 13:09:27+00:00

Tested on 131.0a1 (2024-08-28) BuildID 20240828213451.


STR:

1. Flip `browser.tabs.hoverPreview.enabled` to false.
2. Start playing any audio or video clip in a new tab.
3. Hover the cursor over the tab. The second line of the native tooltip should say "Playing audio".
4. Flip `browser.tabs.hoverPreview.enabled` to back to true.
5. Hover the cursor over the same tab again.

Expected Behavior:

Tab previews should indicate that a tab is "Playing audio".


Actual Behavior:

Unlike the native tooltips, tab previews provide no indication that a tab is "Playing audio".


FWIW Chrom(ium) has a "This tab is playing audio" indicator below the preview thumbnail. The same indicator also shows up in the native tooltip when I disable tab hover previews using the [`#tab-hover-cards`](https://github.com/ungoogled-software/ungoogled-chromium/pull/1727/commits/9c1e5da7cdf0718943f0de6cdd01c0e3e7762b8e) flag in ungoogled-chromium.
Bug: Right-clicking the new tab button in the vertical tab strip does nothing
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-29 15:38:03+00:00
Resolved: 2024-09-25 17:33:38+00:00

Tested on 131.0a1 (2024-08-28) BuildID 20240828213451.

STR:

1. Enable `Vertical Tabs` in Firefox Labs.
2. Right-click on the new tab button in the vertical tab strip.

Expected Behavior:

Right-clicking the new tab button brings up the containers menu (Context: bug 1606265).

Actual Behavior:

Nothing happens.
Bug: MacOS theme differences not passed down to new Sidebar component CSS
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-08-29 15:48:03+00:00
Resolved: 2024-09-01 14:00:02+00:00

`--toolbar-non-lwt-bgcolor` is overridden by the OSX css. However, this doesn't reach the sidebar panel which also uses this variable.
Bug: [Layout Expt] Topsite Padding/Font size Adjustments
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-08-29 18:35:58+00:00
Resolved: 2024-08-30 04:22:44+00:00

Two UX issues: 

- Shortcut tiles spacing (when 2 rows are present) should get 24px of space between each row ([Figma comment](https://www.figma.com/design/zhG60dfgG1ovYnRIGbPQYr?node-id=276-60443#930554531))
- Shortcut tiles should have the same font size as the default UX (Currently too big)

Links: 
- [Figma Designs](https://www.figma.com/design/zhG60dfgG1ovYnRIGbPQYr?node-id=276-60443#930554531) 
- [Breakdown Document](https://docs.google.com/document/d/1ymPRBseT4MJXE0HP2tx_OFXpC_x19PzUr7WTJ50hgpE/edit)
Bug: No option to add languages to each of these boxes in the pop-up window
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-08-29 22:41:17+00:00
Resolved: 2024-08-30 06:49:26+00:00

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

Steps to reproduce:

Opened Translation Settings in:  about:preferences#general


Actual results:

There was no button to add languages to be translated automatically


Expected results:

There should have been buttons to add languages
Bug: Unwanted translation of implicit <option> values
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-08-30 03:03:37+00:00
Resolved: 2024-10-01 14:15:18+00:00

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

### Background

We have [a form](https://tug.org/dvd/request.html) that's written in plain HTML (no JavaScript), and recently we've recently received a few submissions with bogus values. I've traced this down and noticed that when translating a page, Firefox not only translates the text displayed to the user, but also the text sent to the server, leading to unpredictable behaviour.

### Reproduction

1. Open the following test file [(live)](https://www.maxchernoff.ca/files/firefox-translate-test) in Firefox:
    ```html
    <!DOCTYPE html>
    <html lang="en">
        <head>
            <meta charset="UTF-8">
            <title>Firefox Translate Test</title>
        </head>
        <body>
            <select>
                <option>Red</option>
                <option>Orange</option>
                <option>Yellow</option>
                <option value="Green">Green</option>
                <option value="Blue">Blue</option>
                <option value="Purple">Purple</option>
            </select>
            <code>[Initial]</code>
        </body>
        <script>
            const color = document.querySelector("select")
            const result = document.querySelector("code")

            color.addEventListener("change", () => {
                result.textContent = color.value
                result.style.color = color.value
            })
        </script>
    </html>
    ```

2. Change the values of the dropdown to see the text change colour as expected.

3. Translate the page to a different language by opening the hamburger menu, selecting “Translate Page…”, selecting “English → [another language]”, and clicking “Translate”.

4. Change the values of the dropdown again. Notice that the text changes to the expected colours for the last three options with the explicit `value` attribute, but not for the first three options lacking the `value` attribute.

### Problem

The HTML specification states that

> The value of an option element is the value of the value content attribute, if there is one, or, if there is not, the value of the element's text IDL attribute. [(Source)](https://html.spec.whatwg.org/multipage/form-elements.html#attr-option-value)

so by the spec, the following two elements should behave identically:

```html
<option>Red</option>
<option value="Red">Red</option>
```

However, if the page is translated, the first option will have a `value` of `[Red in some other language]` while the second option will have a `value` of `Red`. In addition, translating the page should only change the appearance of the page, and it should not send bogus values to the remote server.

### Solution

I'm not an engine developer, but to me the easiest solution would appear to be to set the `value` attribute to its implicit value if it's not explicitly set before the page is translated. That way, the `value`s should not change when the page is translated.
Bug: The Vertical/Horizontal Tabs radio button deselects if we hide the Sidebar in a second window
Status: NEW
Priority: P2
Created: 2024-08-30 08:16:34+00:00
Resolved: 2024-09-02 12:29:17+00:00

**Found in**
* 131.0a1 (2024-08-30) 

**Affected versions**
* 131.0a1 (2024-08-30) 

**Affected platforms**
* all

**Steps to reproduce**
1. Enable the Sidebar and Vertical Tabs from Firefox Labs 
2. Open Customize Sidebar Settings in a 2nd Window and Select Horizontal Tabs.
3. Open the Customize Sidebar settings in the 1st Window and select Hide Sidebar.

**Expected result**
* The Vertical/Horizontal tabs option should remain checked

**Actual result**
* The Vertical/Horizontal tab option unchecks for the 1st Window.

**Regression range**
Not a regression.
Bug: Revamped sidebar borders have become transparent with the System theme on Linux
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-30 08:46:41+00:00
Resolved: 2024-09-03 14:23:56+00:00

STR:
1. Start with `sidebar.revamp = true` on Ubuntu 24.04.
2. Make sure the theme is set to "System theme" and the bookmarks toolbar is disabled.
3. Drag the window around and observe the page content borders.

The sidebar and top page border are transparent, showing the desktop behind the window.

Does not occur with the Light or Dark theme. The Alpenglow theme is also affected.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=112e5d8b6171cd6a545a51a759d04241ab2cd07c&tochange=0164bfc092727658b3d329a2b416dd1bb19c56b9

Regressed by Bug 1915306.
Bug: [Wayland] Touchpad pinch gestures sometimes don't trigger zooming in PDF documents
Status: UNCONFIRMED
Priority: P3
Created: 2024-08-30 09:04:09+00:00
Resolved: 2024-12-01 15:11:15+00:00

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

Steps to reproduce:

Pinch-to-zoom in and out.


Actual results:

Sometimes the documents is scrolled when I pinch-to-zoom, or sometimes it just idles and nothing happens.  I suspect the reason this bug happens is because Firefox is still loading the document.


Expected results:

The documents should be zoomed.
Bug: Revamped sidebar doesn't deal well with sem-transparent toolbar backgrounds (eg Alpenglow)
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-08-30 09:05:51+00:00
Resolved: 2024-10-10 12:34:24+00:00

STR:
1. Start with `sidebar.verticalTabs = true` and `sidebar.revamp = true` on Ubuntu 24.04.
2. Enable the "Firefox Alpenglow" theme.
3. Expand the sidebar.

Sidebar panel is transparent, showing through to the desktop behind it.

Does not happen on Windows 11.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=73d37e644eb977c4205e20c6a349453f39e09ec4&tochange=f81bc4882ecc99d79404676fdcf3dd5b4355800f

Regressed by Bug 1899336.
Bug: Take screenshot include guides
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-08-30 09:18:24+00:00
Resolved: 2024-09-13 01:15:27+00:00

When a screenshot is taken, that screenshot is including the reference guides, with the dotted lines and the circles in the corners.
Test on 131.0a1 (2024-08-29) (aarch64)
Bug: Revamped sidebar separator draws over the bookmarks toolbar when set to "Only Show on New Tab"
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-08-30 09:46:04+00:00
Resolved: 2024-10-07 08:43:39+00:00

STR:
1. Start with `sidebar.revamp = true`.
2. Make sure the Bookmarks Toolbar is set to "Only Show on New Tab" (default).
3. Open a new tab.
4. Open the History sidebar (Ctrl+H).
5. Hover the mouse cursor over the sidebar separator.

Sidebar separator draws over the bookmarks toolbar. 

Does not happen when the bookmarks toolbar is set to "Always Show".

On Ubuntu 24.04, the overlap is always visible without having to hover and it also overlaps the address bar dropdown.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=936f3047272d1ef5feb4f02953db3ad74c59bbd1&tochange=95109305b579922c59ef5966e60c9397e48847ac

Regressed by Bug 1910733.
Bug: the order in the history gets updated live when any item from it is open (even in new tab), making history very difficult to use
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-30 10:35:30+00:00
Resolved: 2024-08-30 12:31:47+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36

Steps to reproduce:

1. open chrome://browser/content/places/historySidebar.xhtml
2. open any of the history items in a new tab


Actual results:

the item you have just opened moved to the top of the list, which is also scrolled up to the very top


Expected results:

list must stay unchanged

you do not always (often) know which page you need just from the title. when you do - you usually get to it other way than through history

when you do open history - it's usually when there's a level of uncertainty - you remember you read something somewhere but cannot say exactly where - only know general topic and/or approximate time

this is why you open candidates for the right page in new tab - to keep browsing the history and open more than one

shuffling the history in the process of you using it is extremely disturbing - you end up having to scroll / scan it back to the place where you just were after every click/hit!
Bug: history doesn't respect browser.tabs.loadInBackground
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-08-30 10:42:39+00:00
Resolved: 2024-09-18 12:58:38+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36

Steps to reproduce:

1. ensure that you have browser.tabs.loadInBackground set to true

2. open history with ctrl+h or chrome://browser/content/places/historySidebar.xhtml

2. ctrl+click any item


Actual results:

firefox switches to the newly opened tab


Expected results:

the new tab must open in the background, you should remain in the tab active before the click
Bug: Revamped sidebar animation leaves behind a ghost image of the page content when toggle clicked in quick succession
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-08-30 10:42:42+00:00
Resolved: 2024-09-05 07:12:50+00:00

STR:
1. Start with `sidebar.revamp = true`.
2. Rapidly click the sidebar button in the toolbar to expand/collapse it.

A ghost image of the page content sometimes remains, covering the actual content. Dragging the image shows a drag thumbnail.

Occurs on both Ubuntu 24.04 and Windows 11.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=92acbb3b404d41b2fc9a3f5307603d42b70f31fa&tochange=38cc8fd863bbc1136b6a5cc54deaa743e5f1e2ff

Regressed by Bug 1898251.
Bug: Skip recording+testing browser.ui.toolbar_widgets in Artefact Builds until bug 1883857
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2024-08-30 13:15:04+00:00
Resolved: 2024-08-30 22:26:40+00:00

`object` metrics are untestable in artefact builds until bug 1883857 is taken care of. I forgot that when I added an `object` metric to `BrowserUsageTelemetry`  and `assertVisibilityScalars`.
Bug: Vertical tabs that are pinned do not change appearance when hovered and do not clearly show active state
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2024-08-30 13:35:02+00:00
Resolved: 2024-10-31 10:04:17+00:00

STR:
1. Start with `sidebar.verticalTabs = true` and `sidebar.revamp = true`.
2. Pin several tabs.
3. Hover the mouse cursor over an inactive pinned tab.
4. Enable the Dark theme.
5. Select a pinned tab to make it active.

Expected:
Pinned tab changes appearance when hovered and the active tab can be clearly seen.

Actual:
Pinned tab appearance does not change when hovered and active pinned tab is difficult to distinguish from others with Dark theme.

Inactive pinned tabs have an "always hovered" appearance which is inconsistent and makes their hovered/active states less clear. Horizontal pinned tabs do not behave like this and for reference, the popular [Tree Style Tab](https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/) extension does not have this inconsistency.
Bug: browser.tabs.hoverPreview.enabled setting keeps reenabling itself
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-30 19:09:19+00:00
Resolved: 2024-08-30 19:15:13+00:00

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

Steps to reproduce:

Ever since the latest update I've been trying to disable too much stuff showing on mouseovering tabs. I figured two settings in about:config are responsible for this browser.tabs.hoverPreview.showThumbnails and browser.tabs.hoverPreview.enabled
I disabled them. The former one stays disabled, but browser.tabs.hoverPreview.enabled reenables itself each time I restart the browser. 
There have been other reports of this issue, including here:
1) https://bugzilla.mozilla.org/show_bug.cgi?id=1914155 
2) https://www.reddit.com/r/firefox/comments/1f0d8h8/why_do_i_need_to_keep_disabling/
3) https://connect.mozilla.org/t5/discussions/tab-previews-are-annoying/m-p/65950
to list a few.
I myself have tested it on two PCs and many different browser profiles, most of which are barely affected by any sort of customization.


Actual results:

The browser.tabs.hoverPreview.enabled setting reverts to being enabled on browser restart.


Expected results:

It should stay disabled if it's been disabled.
Bug: Firefox Developer-Version 130.0b9-about:config-browser.launcherProcess.enabled-False-Does not drag and drop onto desktop-STOP changing with EVERY UPDATE SUPER PLEASE!!!
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-09-01 04:54:53+00:00
Resolved: 2024-09-01 05:17:22+00:00

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

Steps to reproduce:

about:config
browser.launcherProcess.enabled
<change-to> False
Close Developer 130.0b9
Open Developer 130.0b9


Actual results:

This doesn't work anymore, not on this update. Only way I know how to enable this feature. Pull tab from the active browser window onto desktop as a shortcut.


Expected results:

Drop tab onto desktop. Every Firefox and Firefox Developer update you change this. Please stop this. Why disable this feature. Everybody in the world wants this...

Kind regards, ty
_jo
Bug: Context menu on tab not displayed with tab preview enabled
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2024-09-01 17:54:59+00:00
Resolved: 2024-11-12 15:55:08+00:00

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

Steps to reproduce:

loaded the latest verison and the reload page function was gone


Actual results:

loaded the latest verison and the reload page function was gone
Bug: Full screen has light border on the top/left with vertical tabs enabled
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-09-02 00:17:29+00:00
Resolved: 2024-09-27 13:18:19+00:00

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

Steps to reproduce:

Enable vertical tabs on Firefox nightly
Using default light theme
Open full screen content, like YouTube video in full screen mode


Actual results:

A white border along the top and left of the screen appears, I believe from the recently introduced shadow/border around the viewport for vertical tabs.

Note the 1 pixel border running along the top/left of the attached screenshot.


Expected results:

No border on the top/left of the full screen content.