av9ash/GitBugs huggingface dataset:
Bug: gifv images can flash even if users set image.animation_mode none
Status: NEW
Priority: --
Created: 2022-08-24 02:17:36+00:00
Resolved: 2024-05-16 07:30:55+00:00

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

Steps to reproduce:

For safety, set image.animation_mode to none among other accessibility fixes.


Actual results:

Encountered an image that flashed before loading, loaded, flashed again, and then stayed.

Inspected the image, which seems to be a gifv.


Expected results:

It should not flash or otherwise animate.

The console shows the following error:

Error: Please use $(ref:runtime.getURL). bridge.js:54
    getVersion moz-extension://a0946294-28ed-9a4d-b165-f09f0f3c31a7/bridge.js:54

Mozregression shows this is at least 6 months old, but can't load Tumblr in older versions.

I still get the flash in troubleshoot mode.

I only get the error on my dash, not on a direct link to the post here... https://msaprildaniels.tumblr.com/post/693425016665210880/gender-reveals-are-some-serious-shit
Bug: The text color of Quick actions on mouseover should follow the popup_highlight_text color of theme
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-08-24 03:17:01+00:00
Resolved: 2022-09-29 00:30:34+00:00

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

Steps to reproduce:

1. Apply a custom theme that popup and popup_highlight are opposite colors.
e.g.
  "theme": {
    "colors": {
      "popup": "white",
      "popup_text": "black",
      "popup_highlight": "black",
      "popup_highlight_text": "white"
    }
  }

2. Focus address bar and hovering over Quick actions.


Actual results:

The text of Quick actions is not visible because the text and the background are in the similar color.


Expected results:

The text of Quick actions is visible.
Bug: User is not able to navigate to a particular slide
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2022-08-24 05:19:42+00:00
Resolved: 2022-08-24 13:09:37+00:00

Description:

When user navigates any slides, the option of moving to any particular slide is not present .

Steps To Reproduce:
1.Open the LMS
2.Click on CLASSROOMS link given in the header
3.Click on week1 -> any day
4.Click on any slide and open it
5.User is on 10th slide
6.User wants to go to first slide

Expected:
User can select slide no. from top(as per requirement no. 125: option should come for end user)

Actual:
User is not able to select particular slide
Bug: urlbar command help button opens a 404
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2022-08-24 06:14:12+00:00
Resolved: 2023-06-22 09:40:48+00:00

**Steps to reproduce**
1. Focus the URL bar
1. In the command section, click the `?` button

**Expected results**

The opened page contains some information about urlbar commands

**Actual results**

The opened page, https://support.mozilla.org/en-US/kb/quick-actions-firefox-search-bar?as=u&utm_source=inproduct, is a 404

---

I think the link comes from

https://searchfox.org/mozilla-central/rev/d01591796d5faccf762adb09a311d8ee12f7ca7f/browser/components/urlbar/UrlbarProviderQuickActions.sys.mjs#63-68
```js
get helpUrl() {
  return (
    Services.urlFormatter.formatURLPref("app.support.baseURL") +
    "quick-actions-firefox-search-bar"
  );
}
```
Bug: Intermittent browser/components/urlbar/tests/browser/browser_keyword_select_and_type.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-08-24 07:59:40+00:00
Resolved: 2022-09-20 17:03:41+00:00

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

---
```
[task 2022-08-24T04:41:41.535Z] 04:41:41     INFO - TEST-START | browser/components/urlbar/tests/browser/browser_keyword_select_and_type.js
[task 2022-08-24T04:43:41.549Z] 04:43:41     INFO - TEST-INFO | started process screentopng
[task 2022-08-24T04:43:41.789Z] 04:43:41     INFO - TEST-INFO | screentopng: exit 0
[task 2022-08-24T04:43:41.789Z] 04:43:41     INFO - Buffered messages logged at 04:41:41
[task 2022-08-24T04:43:41.789Z] 04:43:41     INFO - Entering test bound 
[task 2022-08-24T04:43:41.789Z] 04:43:41     INFO - Buffered messages finished
[task 2022-08-24T04:43:41.790Z] 04:43:41     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_keyword_select_and_type.js | Test timed out - 
[task 2022-08-24T04:43:41.791Z] 04:43:41     INFO - GECKO(1660) | MEMORY STAT | vsize 130552508MB | residentFast 2253MB
[task 2022-08-24T04:43:41.793Z] 04:43:41     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_keyword_select_and_type.js | took 120176ms
[task 2022-08-24T04:43:41.793Z] 04:43:41     INFO - Not taking screenshot here: see the one that was previously logged
[task 2022-08-24T04:43:41.793Z] 04:43:41     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_keyword_select_and_type.js | Found a tab after previous test timed out: about:mozilla - 
[task 2022-08-24T04:43:41.923Z] 04:43:41     INFO - checking window state
[task 2022-08-24T04:43:41.958Z] 04:43:41     INFO - TEST-START | browser/components/urlbar/tests/browser/browser_loadRace.js
```
Bug: The title from the left part of the “Language mismatch” screen and the “Switch to <OS Language>” button label are not displayed in the OS language in some circumstances
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-08-24 09:38:29+00:00
Resolved: 2022-08-24 17:21:24+00:00

**[Affected versions]:**
- Firefox Nightly 106.0a1 (Build ID: 20220823214727)
- Firefox Beta 105.0b2 (Build ID: 20220823185840)

**[Affected Platforms]:**
- macOS 12.5.1
- Windows 10 x64
- Ubuntu 20.04 x64

**[Prerequisites]:**
- Have the OS language set to Afrikaans.
- Have the Firefox **it** locale installed and opened.
- Have the “browser.aboutwelcome.templateMR” pref set to true.

**[Steps to reproduce]:**
1. Navigate to the “about:welcome” page.
2. Click the “Skip this step” button from the first screen.
3. Observe the title from the left part of the screen and the “Switch to <OS Language>” button.

**[Expected result]:**
 - The title text from the left part of the screen and the “Switch to <OS Language>” button are displayed in Afrikaans.

**[Actual result]:**
 - The title text from the left part of the screen and the “Switch to <OS Language>” button are displayed in Italian.

**[Notes]:**
- So far, I’ve noticed the following discrepancies:
    - If the **Afrikaans** OS language is set and the **en-US** browser is used: the text and buttons labels are in **en-US** which is a fallback.
    - If the **Afrikaans** OS language is set and the **fr** browser is used: the titles and the body text are in **en-US** (fallback) and the buttons labels are both in **fr**.
    - If the **Afrikaans** OS language is set and the **de** browser is used: the titles and the body text are in **en-US** (fallback) and the buttons labels are both in **de**.
    - If the **Espana (Colombia)** OS language is set and the **it** browser is used: both titles, body text, and the second button are in **it**, and the second button is in **Spanish**.


- If the **English** OS language is set, everything seems to be fine when using a different browser language.
   - If the **English** OS language is set and the **de** browser is used: the titles, the body text, and the first button are in **en-US** (fallback) and the second button label is in **de**. (which is fine, I think)
   - If the **English** OS language is set and the **fr** browser is used: the titles, the body text, and the first button are in **en-US** (fallback) and the second button label is in **fr**. (which is fine, I think)
   - If the **English** OS language is set and the **it** browser is used: the title from the left part of the screen and the first button are in **it**, and the title from the right part of the screen, the body text and the second button are in **en-US**.
- This issue is not reproducible if the **English** OS language is set and the **pt-BR** browser is used.
- Attached is a screenshot of the issue.
Bug: The "Get Firefox Focus" modal is no longer dismissed when the "x" button is clicked
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-24 12:35:21+00:00
Resolved: 2022-09-01 11:51:35+00:00

**[Affected versions]:**
- Firefox Nightly 106.0a1 - Build ID: 20220823214727
- Firefox Beta 105.0b2 - Build ID: 20220823185840

**[Affected Platforms]:**
- Windows 10 x64
- macOS 12.3.1
- Linux Mint 20.2 x64

**[Prerequisites]:**
- Have the new Firefox profile opened.

**[Steps to reproduce]:**
1. Open a new private window and click the “Download Firefox Focus” button.
2. Click the “x” button from the “Get Firefox Focus” modal.

**[Expected result]:**
- The Close button from the “Get Firefox Focus” modal is actionable and the modal is dismissed.

**[Actual result]:**
- The Close button from the “Get Firefox Focus” modal is not actionable and the modal is not dismissed.

**[Regression window]:**
- The issue is not reproducible with older Nightly 104.0a1 builds. Considering this using mozregression tools I have found the regression range. Here are the results:
Last good revision: 43c1a6141f9ddb20447c6e5075612f59405cd9fb
First bad revision: 32f983ac16be4e76e049a2a3c98e8035433727d9
Pushlog: [link](https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=43c1a6141f9ddb20447c6e5075612f59405cd9fb&tochange=32f983ac16be4e76e049a2a3c98e8035433727d9)

From this pushlog it seems that Bug 1758506 may have introduced this behavior.

**[Notes]:**
- The “Get Firefox Focus” modal can be dismissed by pressing the “Esc” key.
- The issue is not reproducible with keyboard navigation, in this case the modal is successfully dismissed.
- Attached is a screen recording of the issue.
Bug: Intermittent browser/components/urlbar/tests/browser/browser_searchFunction.js | single tracking bug
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2022-08-24 14:05:08+00:00
Resolved: 2022-09-20 17:03:51+00:00

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

---
```
[task 2022-08-24T12:15:42.056Z] 12:15:42     INFO - TEST-START | browser/components/urlbar/tests/browser/browser_searchFunction.js
[task 2022-08-24T12:15:42.230Z] 12:15:42     INFO - GECKO(4894) | -----------------------------------------------------
[task 2022-08-24T12:15:42.230Z] 12:15:42     INFO - GECKO(4894) | Suppressions used:
[task 2022-08-24T12:15:42.230Z] 12:15:42     INFO - GECKO(4894) |   count      bytes template
[task 2022-08-24T12:15:42.230Z] 12:15:42     INFO - GECKO(4894) |       2        288 libfontconfig.so
[task 2022-08-24T12:15:42.230Z] 12:15:42     INFO - GECKO(4894) | -----------------------------------------------------
[task 2022-08-24T12:17:12.163Z] 12:17:12     INFO - TEST-INFO | started process screentopng
[task 2022-08-24T12:17:12.487Z] 12:17:12     INFO - TEST-INFO | screentopng: exit 0
[task 2022-08-24T12:17:12.489Z] 12:17:12     INFO - Buffered messages logged at 12:15:42
[task 2022-08-24T12:17:12.491Z] 12:17:12     INFO - Entering test bound init
[task 2022-08-24T12:17:12.492Z] 12:17:12     INFO - Buffered messages finished
[task 2022-08-24T12:17:12.493Z] 12:17:12     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_searchFunction.js | Test timed out - 
[task 2022-08-24T12:17:12.495Z] 12:17:12     INFO - GECKO(4894) | MEMORY STAT | vsize 20976406MB | residentFast 2233MB
[task 2022-08-24T12:17:12.498Z] 12:17:12     INFO - TEST-OK | browser/components/urlbar/tests/browser/browser_searchFunction.js | took 90119ms
[task 2022-08-24T12:17:12.499Z] 12:17:12     INFO - Not taking screenshot here: see the one that was previously logged
[task 2022-08-24T12:17:12.501Z] 12:17:12     INFO - TEST-UNEXPECTED-FAIL | browser/components/urlbar/tests/browser/browser_searchFunction.js | Found a tab after previous test timed out: about:blank - 
[task 2022-08-24T12:17:12.502Z] 12:17:12     INFO - checking window state
[task 2022-08-24T12:17:12.503Z] 12:17:12     INFO - TEST-START | browser/components/urlbar/tests/browser/browser_searchHistoryLimit.js
```
Bug: Content/file handling settings are not retained (handers.json ending up corrupt and being replaced - no data recovery)
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-08-24 14:15:15+00:00
Resolved: 2022-10-14 16:35:57+00:00

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

Steps to reproduce:

Seemingly forever, FF knew to ask me how to handle different file types (pdf, jpg, docx, etc.; asking me if I wanted to save them, or open them in the appropriate app).  Then last year I had to "re-teach" it.  All the file-handling defaults were erased, making the simple act of opening a new file type much more lengthy as I had to reconfigure FF with what to do.  So now with 103.0.2 64-bit, my list of known file types is again chopped to just four - AVIF, XML, SVG, WebP - and I have to again teach it what to do with all the file types.  Wrong, annoying, time consuming.


Actual results:

As outlined, FF forced me to save the document; I then had to go into settings to configure the browser to ask each time.


Expected results:

Settings should retain how to handle file types - versus users having to reteach.  How can I get my prior file handling instructions back into my current browser?
Bug: Hitting secondary CTA on colorways screen after navigating back resets to system theme
Status: VERIFIED
Priority: P3
Resolution: FIXED
Created: 2022-08-24 15:45:05+00:00
Resolved: 2022-08-30 13:34:27+00:00

Scope of this bug is to fix an edge case in new user onboarding that resets user previously applied colorway in the same session.

STR:
1. Open about:welcome
2. Navigate to colorway screen, select a colorway theme and hit Set colorway
3. Colorway should be applied. Navigate back to colorway screen by hitting back button
4. Click secondary CTA 

Expected Result:
Previous selected colorway should stay applied

Actual Result:
Theme gets reset back to system theme
Bug: Secondary CTA is not clickable on Language Mismatch screen while screen is downloading langpack
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2022-08-24 15:57:42+00:00
Resolved: 2022-09-06 14:56:46+00:00

Scope of this bug is to fix an edge case on language mismatch screen. Secondary CTA on Language mismatch screen has label skip and stays inactive while the screen is downloading lang pack (See attached).

STR in local dev:
1.  Clobber and build locally
2. Launch firefox using below command line script
./mach run --setpref "extensions.getAddons.langpacks.url=https://mock-amo-language-tools.glitch.me/?app=firefox&type=language&appversion=%VERSION%" --setpref "intl.multilingual.aboutWelcome.languageMismatchEnabled=true" --setpref "intl.multilingual.aboutWelcome.systemLocaleOverride=es-CO"  --setpref browser.aboutwelcome.templateMR=true -- about:welcome

3. Navigate to Language mismatch screen

Expected Result:
1. Click of secondary CTA should navigate user to next screen

Actual result:
1. Secondary CTA is not clickable
Bug: Devices parameters lost in Development tools
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2022-08-24 17:22:14+00:00
Resolved: 2022-09-27 18:22:37+00:00

Actual results:

Hello,

On a Firefox installation from Mozilla site, with Firefox and Firefox Developer Edition on Ubuntu O/S.

I noticed the loss of the personalized parameters that I had taken care to enter for the preview of the sites in responsive (CTRL + SHIFT + M). I will have to enter everything by hand again. It would be so nice if we could save/restore these custom settings, or at least not lose them...
Bug: Quick Actions urlbar provider should be active for restrict tokens
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2022-08-24 19:20:56+00:00
Resolved: 2022-09-24 22:14:02+00:00

Right now the Quick Actions provider [is active](https://searchfox.org/mozilla-central/rev/d01591796d5faccf762adb09a311d8ee12f7ca7f/browser/components/urlbar/UrlbarProviderQuickActions.sys.mjs#84-90) when not in a search mode or when in the Actions search mode. This works like other providers that have a corresponding search mode.

But typing its [restrict token](https://searchfox.org/mozilla-central/rev/d01591796d5faccf762adb09a311d8ee12f7ca7f/browser/components/urlbar/UrlbarTokenizer.sys.mjs#78) `>` followed by a valid search string doesn't work. Normally, when you type a restrict token like `*` or `%`, followed by a search string, the provider in question will return results equivalent to what it would find in its search mode. You can also type the restrict token and hit Spacebar to enter the Quick Actions search mode, and that works as expected. But for Quick Actions, if you type the restrict token and then immediately type the search string (like `>view source`), you won't get any quick action results.

That's because it isn't added to the context as a source [here](https://searchfox.org/mozilla-central/rev/642be079c4465445ab42b55d18e0a4d644c19c36/browser/components/urlbar/UrlbarProvidersManager.sys.mjs#731), and it's also further complicated because the provider itself only returns results for strings that 1) contain the full keyword, or 2) are fully contained in a keyword. So, once it's added as a source, the search string `>view source` actually does return a quick action result, but the search string `>view sou` does not, because it doesn't contain a full keyword, and none of the keywords contain the restrict token `>`.

So, if the restrict token matches, we should compare the looped prefixes to the input _minus_ the restrict token. Then we will get the same results (from this provider) that we would get if we didn't type the token, or if we were in the Quick Actions search mode.

We should also be able to disable `suggest.quickactions` and still be able to get quick action results by entering the Quick Actions search mode or using the `>` token. The reason we're not able to do that is just because of the `isActive` check — we can just replace `searchMode.source` with `restrictSource` to take advantage of the fact that we added Quick Actions in `updateSourcesIfEmpty`.
Bug: Firefox View logo text weight
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-08-24 20:36:19+00:00
Resolved: 2022-09-09 21:30:08+00:00

Actual: "Firefox View" is displaying in normal text weight. Should be bold h1 styling, same as Tab pickup and Recently closed headers

Expected "Firefox View" font weight = 600 (match H1s)
Bug: Popup blocker  does not handle urls within urls correctly
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-08-24 20:37:19+00:00
Resolved: 2022-10-17 12:50:55+00:00

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

Steps to reproduce:

Example:

https://web.archive.org/save/https://www.somesite.com

Will fail because firefox will detect it as a popup when run from a script and opened in a new tab from the script. It says that somesite.com is a popup and blocks it. I can whitelist somesite.com but it does no good.

I do not remember having this problem until I updated firefox developer a few weeks ago and it doesn't seem to always occur. 

window.open("https://web.archive.org/save/https://www.somesite.com");

will be blocked(at some point(may have to open several tabs using it or other sites)). archive.org and somesite.com are whitelisted(although only archive.org should be as the inside url has nothing to do with popup blocking).

This seems like a bug in how the url is parsed for pop-up blocking.




Actual results:

New tab link opened from a script in another tab is blocked.


Expected results:

It should not be blocked. The actual website is whitelisted(in fact, they all are).
Bug: [List all tabs Button] Position of the new always visible button looks misplaced on the Tabstrip on Mac
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-08-24 20:38:44+00:00
Resolved: 2022-09-30 06:26:58+00:00

Nightly 106.0a1 (2022-08-24) (64-Bit)
MacOS 12.5.1

1.) Open a new Window 
2.) Open an Incognito Window

Actual:

The position of the new always visible button looks misplaced on the Tabstrip on Mac.

Expected: 
In Normal Window: The button should be placed over the preference button. 
In Incognito Window: The button should be placed over the pocket button and the Incognito badge should be placed exactly over the preference button. 

Thanks.
Bug: [List all tabs Button] Missing padding below last item in the Tab Groups Section Menu
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2022-08-24 20:54:38+00:00
Resolved: 2022-09-08 12:19:06+00:00

Nightly 106.0a1 (2022-08-24) (64-Bit)
MacOS 12.5.1

1.) Open a new Window
2.) Click on the List all tabs Button
3.) Open the Tab Groups Section
4.) Hover over Manage Tab Groups item at the bottom of the menu

Actual: Padding between the hover button and the border of menu is missing.

Expected: There should be padding between the hover button and the border of menu 

A screenshot of the issue is attached.

Thanks
Bug: Match font sizes in tab pickup cards to Figma spec
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-08-24 21:43:54+00:00
Resolved: 2022-09-09 04:33:40+00:00

Actual: Various font sizes in tab pickup cards are coded as .85em (13px) and should be .75em(11px). Please see attachment for diagram
Expected: Font sizes in tab pickup map to figma sizes specified
Bug: Timestamps in tab pickup and recently closed should always appear on one line
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2022-08-24 21:53:19+00:00
Resolved: 2022-09-21 12:08:27+00:00

Actual: Timestamps in tab pickup and recently closed are wrapping
Expected: Timestamps in tab pickup and recently closed always appear on one line. If we have to further truncate title to do this, we're ok with that. 

Related to 1785234 - https://bugzilla.mozilla.org/show_bug.cgi?id=1785234
Bug: Adjust color-mix for secondary text to better align with design spec
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2022-08-24 22:17:58+00:00
Resolved: 2023-06-02 15:23:37+00:00

Actual
Secondary text color = color-mix(in srgb, currentColor 80%, transparent)

Expected
Secondary text color = color-mix(in srgb, currentColor 60%, transparent)

This should be applied on new tab page and on Fx View for consistency
Bug: Clicking on an item in the history window delivers attention to the requested item, but returns the history window to top level, removing user from selected focus entirely
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2022-08-25 02:18:22+00:00
Resolved: 2022-09-22 15:43:42+00:00

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

Steps to reproduce:

Open "show all history". Find a desired page from history. Double click. 


Actual results:

Selected page from history opens on active firefox browser window or opens a new window and directs to selected item from history. The history window returns to top level, creating a frustrating experience if you selected the desired item.


Expected results:

Selected page from history opens on active firefox browser window or opens a new window and directs to selected item from history. The history window does NOT return to top level showing all items.