av9ash/GitBugs huggingface dataset:
Bug: Intermittent browser/components/search/test/browser/telemetry/browser_search_telemetry_categorization_experiment_info.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2024-08-01 16:02:31+00:00
Resolved: 2024-08-05 06:39:37+00:00

**Filed by:** jteow [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=468429049&repo=try
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/baDNZhopQhKQ2NI7h2O1jw/runs/0/artifacts/public/logs/live_backing.log

---
```

```
Bug: Standardize font sizes in Sidebar component.
Status: NEW
Priority: P3
Created: 2024-08-01 16:30:19+00:00
Resolved: 2024-08-20 12:17:33+00:00

In https://phabricator.services.mozilla.com/D216748 the root font size was set to 15px as per the specs and to ensure space tokens were the correct pixel values. It was brought up that this may break standard ways to customize UI font sizes so will need further discussion.
Bug: Recommended Stories title doesn't always show correct string when topics are selected
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2024-08-01 18:32:17+00:00
Resolved: 2024-08-03 09:55:42+00:00

### Steps to Reproduce

##### Setup: 
- Set `browser.newtabpage.activity-stream.discoverystream.topicSelection.enabled` to true.
- Make note if any of the following are true:
  - `browser.newtabpage.activity-stream.discoverystream.topicSelection.hasBeenUpdatedPreviously` is True
  - `browser.newtabpage.activity-stream.discoverystream.topicSelection.selectedTopics` is NOT empty (Has categories in it)

##### Testing steps: 
1. Select a topic, change it, something, but make sure it's not empty.
1. Set "browser.newtabpage.activity-stream.discoverystream.topicSelection.hasBeenUpdatedPreviously" to false.
1. Make a topic update.
1. Expected: The title should read "Today’s picks for you"
1. Actual: Title remains the same as previous: "Thought-provoking stories"
Bug: Private browsing history is recorded in targeting snapshot
Status: RESOLVED
Priority: P1
Resolution: WORKSFORME
Created: 2024-08-02 08:41:50+00:00
Resolved: 2024-09-09 17:35:16+00:00

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

Steps to reproduce:

With Firefox set to "never remember history", use the browser as normal for long enough for "targeting snapshot" to update.


Actual results:

A selection of websites visited are recorded in targeting.snapshot.json as topFrecentSites


Expected results:

Browsing history is not recorded.
Bug: Content in hover preview is influenced by the size of the browser size leading to unusable content displayed in preview
Status: NEW
Priority: P3
Created: 2024-08-02 12:39:41+00:00
Resolved: 2024-11-26 05:09:04+00:00

**Found in**
* Latest Nightly 130.0a1

**Affected versions**
* Nightly 130.0a1

**Tested platforms**
* Affected platforms: Windows 11, macOS 13.4 and Ubuntu 22.04
* Unaffected platforms: 

**Preconditions**
* `browser.tabs.hoverPreview.enabled` - `true`

**Steps to reproduce**
1. Use a new profile
2. Visit facebook, youtube and a few more websites
3. Hover over the tabs and notice the content from these particular websites from above
4. Resize the height of the browser considerably
5. Hover over facebook and youtube websites

**Expected result**
* The content shown in the preview remains the same even if the browser window size is changed.

**Actual result**
* The cookie banner from these websites and others are resized or placed in different places in the preview.

**Regression range**
* This happens after bug 1906123 got fixed before this the behavior was totally different so this is not a regression per se.

**Additional notes**
* I noticed that the content in the page is also altered depending on the size of the browser window even though the page has no cookies banner. This is something that Chrome for example does not do, they have a consistent sized image of the content in preview no matter the size of the browser window.
Bug: Tab Crash on mouse hover for alt text
Status: NEW
Priority: --
Created: 2024-08-02 12:40:16+00:00
Resolved: 2024-08-05 18:40:52+00:00

Crashes with ` [76147] Hit MOZ_CRASH(MouseEvent target must be an element) at /Users/tarekziade/Dev/mozilla-central/layout/base/PresShell.cpp:9023`

Steps to reproduce the problem:
1. enable inference (browser.ml.enable and pdfjs.enableAltText)
2. load a PDF
3. wait for the alt text to be filled
4. hove the mouse on the alt text widget without clicking
5. tab crashes

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)
Bug: Search tip is not displayed after an update
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2024-08-02 14:04:16+00:00
Resolved: 2024-09-10 06:25:22+00:00

**Found in**
* Fx 130.0a1

**Affected versions**
* Fx 130.0a1

**Affected platforms**
* Ubuntu 23.04

**Preconditions**
Have an older version of nightly installed.

**Steps to reproduce**
1. Launch Firefox.
2. Go to about:config and switch devtools.chrome.enabled to true.
3.  Input the following snippet in the browser console:
(async function() { let { ProfileAge } = ChromeUtils.import("resource://gre/modules/ProfileAge.jsm"); let age = await ProfileAge(); age._times = { firstUse: 1368255600000, created: 1368255600000 }; await age.writeTimes(); })();
4. In about:preferences disable the 'default browser' check.
5. Update and restart the browser to apply it.
    5.1. No "search tip" is displayed after the restart on a newly opened tab
6. Close the browser.
7. Go to the install folder and delete the update.xml file (and active-update.xml if it exists).
8. Open Firefox again.


**Expected result**
* URL section is highlighted and focused. There is a Search tip displayed.

**Actual result**
* No search tip is displayed.

**Regression range**
* Will look into a regression range ASAP.
Bug: FullPageTranslationsPanel Translate button no longer correctly reacts to language changes
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-08-02 16:17:20+00:00
Resolved: 2024-08-22 08:10:50+00:00

### Description

Bug 1891792 landed some code that changed the way events are handled in the FullPageTranslationsPanel. 

Unfortunately, our automated test coverage was missing a specific case that would fail if the Translate button did not correctly become re-enabled when selecting a valid language pair if an invalid language pair was previously selected. 

---

### Steps to reproduce #1

> Note: The following STR should be tested both by selecting the new language value using the mouse, and by selecting the new language value by focusing the menulist with `TAB`, then using the arrow keys.

* Open a translatable web page, e.g. https://es.wikipedia.org/wiki/Mozilla_Firefox
* Open the Full-Page Translations Panel.
* Verify that valid languages are selected and that the Translate button is enabled.
* Change the selected from-menu-list value to the "Choose a language" option.

**Expected behavior**
The translate button becomes disabled.

**Actual behavior**
The translate button does not change.

* Change the selected from-menu-list value back to a language that is not the same as the selected to-menu-list value.

**Expected behavior**
The translate button becomes re-enabled.

**Actual behavior**
The translate button does not change.

* Change the selected from-menu-list value back to the same language as the selected to-menu-list value.

**Expected behavior**
The translate button becomes disabled.

**Actual behavior**
The translate button does not change.

### Steps to reproduce #2

> Note: The following STR should be tested both by selecting the new language value using the mouse, and by selecting the new language value by focusing the menulist with `TAB`, then using the arrow keys.

Repeat the process of STR #1, but change the to-menu-list values instead of changing the from-menu-list values.

---

### Tests to implement

* We should add new test cases that ensure this behavior has coverage.
* These tests should ensure that the telemetry is correct as well.
Bug: Consider using rem or em as the unit for the new sidebar widths
Status: NEW
Priority: P3
Created: 2024-08-02 19:00:57+00:00
Resolved: 2024-08-20 10:01:08+00:00

Our current (sidebar.revamp=false) sidebars define a width and min-width as 18em and 14em respectively in [sidebar.css](https://searchfox.org/mozilla-central/rev/7279a1df13a819be254fd4649e07c4ff93e4bd45/browser/themes/shared/sidebar.css#13-33). This ensures that line lengths in the sidebar are at least a minimum number of characters long even if the user has a much larger font-size set (via system large fonts, or text-zoom). 

In the new sidebars which are enabled with sidebar.revamp=true, and in bug 1911194, we set the width and min-width in px values. I think if the point is to keep the sidebar legible (rather than line up with some other thing whose dimensions are defined in px) we should continue to use a font-size-relative unit like em or rem. We can calculate an approximate rem value for the target pixel dimensions for firefox and system defaults to correspond to pixel values provided in UX specs, so there should no visual change for most users.
Bug: Prevent defaultBrowserCheck trigger on startup after Profile Refresh
Status: NEW
Priority: P1
Created: 2024-08-03 03:28:19+00:00
Resolved: 2024-10-16 13:05:41+00:00

Startup messages are currently triggering on the first startup after Profile Refresh, which is problematic because the process is not considered "finished" at this point. It seems that the browser (see SessionMigration.sys.mjs) writes about:welcomeback to the new profile's session store so that, after launching it, about:welcomeback will be restored as the active tab, and the flow should pick up from there. So, showing a spotlight modal on top of this page is a confusing experience.

I think this can be avoided by writing a flag to the session store state on migration (SessionMigration.sys.mjs), and then checking for that flag before we fire the defaultBrowserCheck trigger, to avoid firing it for users who are restoring after a profile refresh or other similar actions. It may also be possible to use some existing state, like `browser.sessionstore.resume_session_once` or `SessionStore.willAutoRestore` - but I don't know if those continue to return `true` even on the startup _after_ restore. I spotted them [over here](https://searchfox.org/mozilla-central/rev/9993372dd72daea851eba4600d5750067104bc15/browser/components/migration/FirefoxProfileMigrator.sys.mjs#227) which briefly made me optimistic that we wouldn't need to add any new code, but these may not survive the profile migration or may be cleared before [our trigger](https://searchfox.org/mozilla-central/rev/9993372dd72daea851eba4600d5750067104bc15/browser/components/BrowserGlue.sys.mjs#4855).

ni?mconley - I figured you'd be able to help us with the question above and review our patch if we end up needing to add some persistent state that we can check on the following startup. Thank you!
Bug: PDF viewer doesn't remember the last position of local PDF files
Status: NEW
Priority: --
Created: 2024-08-03 09:09:43+00:00
Resolved: 2025-02-22 20:29:07+00:00

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

Steps to reproduce:

1. Open any local PDF file in Firefox.
2. Go to any desired page.
3. Close the window/tab.
4. Open the same PDF file.
5. It will open on the first page, not where you left off last time.


Actual results:

Firefox doesn't remember the last position of any local PDF files.


Expected results:

After reopening an already viewed PDF, Firefox should open it on the page where it left off.
Bug: The built-in translator in Firefox does not start automatically
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-08-04 15:16:35+00:00
Resolved: 2024-09-11 18:42:35+00:00

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

Steps to reproduce:

I am on Debian 12, I use Firefox ESR which comes with my OS, I added Firefox in Flatpack version and the standard version of Firefox via the official Mozilla repository (packages.mozilla.org).


Actual results:

With Firefox ESR version and Firefox version from Mozilla repository automatic translation does not work

With Firefox Flatpack version, it works ?!

The translation button is also very poorly located ;-( It is on the right of the browser in the "application menu", whereas it should be accessible as for Chromium via the right mouse button!!! The current situation is extremely disabling for everyday use ;-(


Expected results:

Translation should be automatic in all cases.

The user interface should be more accessible and more functional.
Bug: The built-in translator in Firefox does not start automatically
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-04 15:16:45+00:00
Resolved: 2025-02-04 11:53:34+00:00

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

Steps to reproduce:

I am on Debian 12, I use Firefox ESR which comes with my OS, I added Firefox in Flatpack version and the standard version of Firefox via the official Mozilla repository (packages.mozilla.org).


Actual results:

With Firefox ESR version and Firefox version from Mozilla repository automatic translation does not work

With Firefox Flatpack version, it works ?!

The translation button is also very poorly located ;-( It is on the right of the browser in the "application menu", whereas it should be accessible as for Chromium via the right mouse button!!! The current situation is extremely disabling for everyday use ;-(


Expected results:

Translation should be automatic in all cases.

The user interface should be more accessible and more functional.
Bug: The built-in translator in Firefox does not start automatically
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-04 15:19:55+00:00
Resolved: 2025-02-04 11:54:36+00:00

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

Steps to reproduce:

I am on Debian 12, I use Firefox ESR which comes with my OS, I added Firefox in Flatpack version and the standard version of Firefox via the official Mozilla repository (packages.mozilla.org).


Actual results:

With Firefox ESR version and Firefox version from Mozilla repository automatic translation does not work.

With Firefox Flatpack version, it works ?!

The translation button is also very poorly located ;-( It is on the right of the browser in the "application menu", whereas it should be accessible as for Chromium via the right mouse button!!! The current situation is extremely disabling for everyday use ;-(


Expected results:

Translation should be automatic in all cases.

The user interface should be more accessible and more functional.
Bug: Redirects to file:// URLs ignore setting network.protocol-handler.external.file
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2024-08-04 20:59:31+00:00
Resolved: 2024-08-27 22:21:15+00:00

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

Steps to reproduce:

We have an environment of some internal websites (stuff like a wiki and similar software) where links to file:// URLs should open either the default application of the system or even the file explorer for links to directories. This can be achieved using the "LocalFileLinks" policy in "policies.json" (or using a GPO) in combination with "network.protocol-handler.expose.file" = false and "network.protocol-handler.external.file" = true in "about:config". This works great for different sites where the link to the file:// URL is a direct link (the "href" of <a>-tags).

Now we are evaluating another software where the links first go to the application using HTTP(S). The application then serves a redirect (301) to the local file:// URL. This is probably to keep track of clicked links, as this would not be possible with "direct" links to the file system.

Since our internal setup might be difficult to reproduce, I decided to setup a small NodeJS project that emulates the behaviour of the software: https://github.com/lukoerfer/firefox-file-redirects


Actual results:

Instead of just launching the respective application as configured for the file:// URL using "network.protocol-handler.external.file", Firefox will try to open the file on its own. When the file is a PDF, Firefox will use its internal PDF viewer. I know that this behavior can be changed in Firefox, but I want to keep this behavior for files requested via HTTP(S). When the file is something like a PowerPoint (.pptx), Firefox will open a dialog asking if the file should be opened or saved to some location (which does not make sense for a local file).


Expected results:

Firefox should open file:// URLs using the respective application of the system, even when the file:// URL comes from a redirect of a HTTP(S) request.
Bug: v128 suddenly ignores "tag" in bookmarks
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-04 23:45:06+00:00
Resolved: 2024-08-26 13:13:02+00:00

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

Steps to reproduce:

Add the following 2 URLs as bookmarks:
https://en.wikipedia.org/wiki/Main_Page#p-search
https://www.perplexity.ai/

add "w" as a "tag" in the wikipedia url bookmark
now click into the url bar and type "w"


Actual results:

See this screenshot:

https://i.postimg.cc/ZRBxvzGV/search.jpg


Expected results:

the wiki bookmark url with "w" tag should be suggested in the URL bar instead of the other bookmark, as I pressed "w" in URL bar.
Bug: [Experiment] [Branch A] The “Recommend add-ons media” callout is still appearing even if the user has selected “Don't show this recommendation again” option
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2024-08-05 09:30:08+00:00
Resolved: 2024-08-08 11:44:39+00:00

**[Affected versions]:**
- Firefox build version >= 123

**[Affected Platforms]:**
- Windows 10 x64
- macOS Ventura 13.6
- Ubuntu 22.04 x64

**[Prerequisites]:**
- Have a Firefox build version >=123.
- Have a new Firefox profile.
- Be enrolled in the treatment A branch of the [experiment](https://experimenter.services.mozilla.com/nimbus/recommend-media-extension-add-ons-part-2/summary).


**[Steps to reproduce]:**
1. Open the Firefox browser.
2. Observe the top right part of the page.
3. Click the “Don’t show this recommendation again” option from the “Recommend add-ons” callout.
4. Change the system’s time to 24h into the future.
5. Restart the browser.
6. Observe the behavior.


**[Expected result]:**
- The “Recommend media” callout is not displayed again.

**[Actual result]:**
- The “Recommend media” callout is displayed again even if the “Don't show this recommendation again” option has been selected.

**[Notes]:**
- A video of this issue is attached.
- This issue is not reproducing on Treatment B and C, and after further investigations we think that the issue is related to the “id” because on treatment B and C the id is: "id": "MEDIA_ADDONS_PT_2_EARLY_DAYS_FEATURE_CALLOUT" and for treatment A it is:  "id": "MEDIA_ADDONS_FEATURE_CALLOUT"
Bug: "Select topics to fine-tune your feed" popup doesn't have any :hover or :active styling for its "Learn how we protect and manage data" link
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2024-08-05 11:04:17+00:00
Resolved: 2024-08-22 13:22:49+00:00

STR:
1. Trigger the "Select topics to fine-tune your feed" popup in the new-tab
(I'm not sure how to trigger this UI on-demand; it appeared automatically for me at Firefox startup, after an update)
2. Hover the "Learn how we protect and manage data" link at the bottom-left of that popup.
3. Try to click-and-drag that link.

ACTUAL RESULTS:
In step 2 and 3, the link doesn't change its color or styling at all.

EXPECTED RESULTS:
The link should change to reflect that it's hovered and/or being activated.
Bug: [Experiment] Users who don't have Firefox set as the default browser are enrolled in the experiment
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2024-08-05 12:05:03+00:00
Resolved: 2024-09-03 22:35:55+00:00

**[ Notes]:**
- Based on the [Experiment Brief document](https://docs.google.com/document/d/1Gqc7KrUm-wh46ZSWaq7FPDwtc44pCtlDDHLmqVAvEIw/edit#heading=h.r63sl22pcwi4), the experiment should exclude users that don't have Firefox set as the default browser.
- However, it seems that this targeting is missing in the [Experimenter page](https://experimenter.services.mozilla.com/nimbus/improved-mailto-handling-with-os-integration/summary).

**[Affected versions]:**
- Firefox 128.0.2 (Build ID: 20240722223746)
- Firefox RC 129.0 (Build ID: 20240729133145)
- Nightly 130.0a1 (Build ID: 20240730164742)

**[Affected Platforms]:**
- Windows 10
- Windows 11

**[Prerequisites]:**
- Have a Firefox en-US build installed.
- Make sure Firefox is NOT set as the default browser.
- Have the following [user.js](https://drive.google.com/file/d/14rFn8KSjEivtxmCVKwbanDZcLZFXY4CB/view?usp=sharing) downloaded in your computer. The user.js contains an ID that will help in natural enrolling in the treatment-a branch of the experiment.

**[Steps to reproduce]:**
1. Open the browser using the profile from the prerequisites.
2. Navigate to about:support page.
3. Click the "Open Folder" button from the "Profile Folder" section.
4. Paste the user.js downloaded from prerequisties.
5. Restart the browser.
6. Navigate to about:studies and observe the enrolled experiments.

**[Expected result]:**
- The profile is not enrolled in the "Improved mailto handling with OS integration" experiment.

**[Actual result]:**
- The profile is enrolled in the "Improved mailto handling with OS integration" experiment.
Bug: Intermittent browser/components/search/test/browser/telemetry/browser_search_telemetry_sources_in_content.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2024-08-05 12:36:44+00:00
Resolved: 2024-09-04 12:01:24+00:00

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

---
```
[task 2024-08-05T11:13:59.276Z] 11:13:59     INFO - TEST-PASS | browser/components/search/test/browser/telemetry/browser_search_telemetry_sources_in_content.js | Recorded and expected abandonment counts match. - 0 == 0 - 
[task 2024-08-05T11:13:59.277Z] 11:13:59     INFO - Leaving test bound test_source_refinement_button_clicked_no_partner_code
[task 2024-08-05T11:13:59.278Z] 11:13:59     INFO - Entering test bound test_source_refinement_button_clicked_with_partner_code
[task 2024-08-05T11:13:59.279Z] 11:13:59     INFO - Buffered messages finished
[task 2024-08-05T11:13:59.280Z] 11:13:59     INFO - TEST-UNEXPECTED-FAIL | browser/components/search/test/browser/telemetry/browser_search_telemetry_sources_in_content.js | Test timed out - 
[task 2024-08-05T11:13:59.281Z] 11:13:59     INFO - GECKO(2062) | Completed ShutdownLeaks collections in process 2062
[task 2024-08-05T11:13:59.282Z] 11:13:59     INFO - TEST-START | Shutdown
```
Bug: Context menu isn't invocable at `about:preferences`.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2024-08-05 16:37:51+00:00
Resolved: 2024-08-23 23:19:29+00:00

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

Steps to reproduce:

I secondary-clicked (or invoked the `ContextMenu` key).


Actual results:

Nothing appeared.


Expected results:

A context menu should have appeared, so that I could utilize the items in it (like "Select All", or extension actions, like SingleFile's ability to save the page).