av9ash/GitBugs huggingface dataset:
Bug: No persistent FF account login after upgrade  to 80 - no sync with own sync server
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-09-05 10:33:07+00:00
Resolved: 2020-09-05 16:56:21+00:00

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

Steps to reproduce:

Upgraded FF on Windows 10 and Linux Mint Ulyana (20) to 80. Tried to continuously use my own sync server hosted on own server that worked flawlessly with FF < 80.


Actual results:

Menu shows yellow warning sign and requests me to log into my FF account. After login, yellow warning sign shows again, requesting me again to log into my FF account, and so on.

Additionally (and maybe caused by the login problem), syncing bookmarks via my own sync server has stopped working. It still works on my office PC with FF < 80.


Expected results:

FF should acknowledge a successful login into my FF account and should sync my bookmarks via my own sync server, as it worked before upgrading FF to 80.
Bug: Firefox doesn't use the xdg-based default on Linux to open files
Status: NEW
Priority: P5
Created: 2020-09-05 12:42:40+00:00
Resolved: 2023-11-16 16:26:21+00:00

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

Steps to reproduce:

On my system, I have Gwenview for opening images and Okular for opening PDFs. In my KDE system settings, Gwenview is listed as the first option for opening images. In Firefox, when I open an image by downloading it and clicking on it from the downloads dropdown, it opens Okular.


Actual results:

When opening images, Firefox uses the first application in mimeinfo.cache. In my case, this is either Okular or Chromium, depending on if I have Chromium installed.

What I think is happening is that Firefox is using the first option in /usr/share/applications/mimeinfo.cache instead of the actual defaults. I believe this because if I install Chromium alongside Firefox, it becomes the first application in mimeinfo.cache and is then used by Firefox for images. This is the listing for PNGs in mimeinfo.cache with Chromium installed:

image/png=chromium.desktop;okularApplication_kimgio.desktop;org.kde.gwenview.desktop;org.kde.mobile.okular_kimgio.desktop;

If I run xdg-mime query default image/png, I get the correct application (org.kde.gwenview.desktop).

I am running Arch Linux with the latest Firefox Nightly. My desktop environment is KDE Plasma.


Expected results:

Firefox should open images with the default application for images. In my case, this is Gwenview.
Bug: Vertical scroll bar disappears after loading a specific web page
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-09-05 12:59:23+00:00
Resolved: 2020-12-16 11:41:15+00:00

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

Steps to reproduce:

The vertical scroll bar disappears after loading the following web page.

https://www.handelsblatt.com/


Actual results:

The vertical scroll bar disappears after loading is complete.


Expected results:

The vertical scrollbar should not disappear.
Bug: Videos hang firefox
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-09-05 14:47:50+00:00
Resolved: 2020-09-07 12:23:54+00:00

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

Steps to reproduce:

Visiting a webpage that will load a video, other than Youtube, will hang Firefox entirely (including all other Firefox windows) until I force it to close.
Example: Imgur, it will load images, but no videos. It will try to load videos, but it will hang.
Most websites are inaccessible without freezing, if they have a video to load.


Actual results:

Hanging, freezing, I can see the spinning loading wheel on the tab up top.
I'm worried if I may have been attacked, or someone could possibly use this to hang the user's input and load their scripts.


Expected results:

It should have loaded the webpage and videos fine.
Bug: Cannot open PDF files
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-09-05 14:58:11+00:00
Resolved: 2020-09-17 06:52:40+00:00

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

Steps to reproduce:

Try to open a local PDF file.


Actual results:

It kept loading and nothing appeared other than a loading animation.


Expected results:

Loaded almost immediately.
Bug: Add Search Engine request does not send session cookies
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-09-05 22:07:11+00:00
Resolved: 2020-09-09 20:30:56+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36

Steps to reproduce:

Navigate to a site that includes a valid OpenSearch <link> element, click on the elipsis on the URL bar, and click on "Add Search Engine".

This site is behind a login, thus a session cookie (and certs) are required)


Actual results:

The <link> element points to a page that hosts the search engine XML, however, the session cookies were not included in the request, so the target page 302-redirects the browser to a login page.   The browser then tries to interpret this login page as if it were XML, and throws the following errors. 



OpenSearchEngine: _onLoad: Failed to init engine! 
Exception { name: "NS_ERROR_FILE_CORRUPTED", message: "https://www.internalfb.com/intern/bunny/opensearch/ is not a valid search plugin.", result: 2152857611, filename: "resource://gre/modules/OpenSearchEngine.jsm", lineNumber: 386, columnNumber: 0, data: null, stack: "_initFromData@resource://gre/modules/OpenSearchEngine.jsm:386:24\n_onLoad@resource://gre/modules/OpenSearchEngine.jsm:295:14\nonStopRequest@resource://gre/modules/SearchUtils.jsm:74:10\n", location: XPCWrappedNative_NoHelper }
OpenSearchEngine.jsm:297:18


Invalid search plugin due to namespace not matching. OpenSearchEngine.jsm:385
    _initFromData resource://gre/modules/OpenSearchEngine.jsm:385
    _onLoad resource://gre/modules/OpenSearchEngine.jsm:295
    onStopRequest resource://gre/modules/SearchUtils.jsm:74


Expected results:

When the browser attempts to retrieve the Search Engine XML specification, it should include available cookies. 

As far as I can tell, the request is set up in resource://gre/modules/SearchUtils.jsm:211.  ( MakeChannel(url) {... )

According to this file [ https://searchfox.org/mozilla-central/source/netwerk/base/nsILoadInfo.idl#136 ] Cookies should be included by default,  but it doesn't seem to be the case for me.
Bug: GIF rendered as blurry on page despite being crisp if loaded individually
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-09-06 00:41:26+00:00
Resolved: 2020-09-08 13:18:37+00:00

Page at:
http://lloydwood.users.sourceforge.net/Personal/L.Wood/satellite-orbits-diagram/
has a 600 by 600 pixel gif in a table at right.

In firefox this gif shows as blurry, even though HEIGHT=600 WIDTH=600 is specified in IMG tags. It does not show as blurry when the graphic is loaded in directly:
http://lloydwood.users.sourceforge.net/Personal/L.Wood/satellite-orbits-diagram/satellite-orbits-figure.gif

or in other browsers (Edge, Chrome), where it is crisply rendered in the page.
Bug: Unable to open Firefox
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-09-06 12:50:11+00:00
Resolved: 2020-10-08 07:33:52+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36

Steps to reproduce:

Ive downloaded and installed Firefox on MacBook Air (running Catalina) and Im unable to even run FF. When I click on the icon in Dock (lower mid-screen), icon starts to hop up and down (indication that OS tries to open FF), but after about 1 min, popup appears saying that FF crashed. Thats it


Actual results:

Like above


Expected results:

FF should start as any other app
Bug: button in a website doesn't work
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-09-06 16:50:36+00:00
Resolved: 2020-09-15 12:55:14+00:00

User Agent: Mozilla/5.0 (Android 8.0.0; Mobile; rv:80.0) Gecko/80.0 Firefox/80.0
Firefox for Android

Steps to reproduce:

Just connect to
https://www.marmiton.org/recettes/recette_pate-a-crepes-des-plus-raffinees_49665.aspx#
and try to charge numbers of pancakes(" crepes" in french)
it was working before branch80,0 ... but now it's Ko.


Actual results:

the button actually DO NOT CHANGE quantities, and before, it was working,


Expected results:

quantities should have changed.
Bug: PDF Outlines not working on an opened document in FIrefox
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-09-07 07:27:28+00:00
Resolved: 2021-03-29 17:48:33+00:00

**Affected versions**
- Firefox 80.0.1
- Firefox 81.0b7
- Firefox 82.0a1 

**Affected platforms**
- Windows 8.1
- macOS 11

**Steps to reproduce**
1. Launch Firefox
2. Access a pdf, for [example](http://www.pdf995.com/samples/pdf.pdf)
3. Open the document's sidebar if it is not automatically opened
4. Click on an outline of choice

**Expected result**
- The page jumps to the selected outline title

**Actual result**
- Nothing happens, and if page is scrolled down, it will jump to top when outlines are clicked

**Regression range**
- Will see for a regression.

**Additional notes**
- The issue can be seen in the attachment

**Suggested severity**
- S4
Bug: Firefox URL-suggestion slow at recognizing tab-change on wikipedia
Status: NEW
Priority: P5
Created: 2020-09-07 08:12:26+00:00
Resolved: 2022-05-12 12:30:03+00:00

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

Steps to reproduce:

1. Visit https://en.wikipedia.org/wiki/Main_Page#p-search
2. save that URL as a bookmark
3. enter "Firefox" in wiki search box
4. now, be fast: hit Enter and then directly press LCtrl+T (new tab) and enter "wiki".


Actual results:

URL suggestion suggests switching to the Wikipedia tab.


Expected results:

FF should, upon user pressing Enter in step 4 directly realize that the bookmark page has been altered and thus URL suggestion should suggest opening the bookmark page, instead of suggesting to switch to the wikipedia tab.
the 4 steps can also be repeated with waiting 2 seconds before pressing LCtrl+T and entering "wiki", in that case you can see that after 2 sec FF finally realized that the original bookmark tab was altered (since it changed to the URL https://en.wikipedia.org/wiki/Firefox by then)
Bug: searchengine-devtools has XSS vulnerabilities in configuration handling
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-09-07 09:34:44+00:00
Resolved: 2021-11-23 07:34:20+00:00

This is a follow-up to bug 1660282. That bug has stopped the XSS for the display of various elements on the UI, but we still need to sanitise / check the configuration before we pass it to the back-end and use it.

I have a few ideas on how to do that, will hopefully get time to look later this week.
Bug: pdf viewer marking text
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-09-07 11:03:26+00:00
Resolved: 2021-10-25 09:48:13+00:00

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

Steps to reproduce:

I marked a word or short phrase in the PDF Viewer and copied it / used it in Google search context menue.  


Actual results:

The text gets highlighted in pink. However not the highlighted text get copied but the text in the line right above the highlighted word/phrase.


Expected results:

The marked/highlighted phrase should be copied.
Bug: Intermittent test_list_json_locale.js | test_listJSONRegionOverride - [test_listJSONRegionOverride : 85] Should have the correct engine list - ["Test search engine","engine-pref","engine-resourceicon","engine-chromeicon"] deepEqual ["Test search engine"
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2020-09-07 16:36:24+00:00
Resolved: 2020-09-14 06:16:53+00:00

**Filed by:** archaeopteryx [at] coole-files.de
**Parsed log:** https://treeherder.mozilla.org/logviewer.html#?job_id=315028129&repo=try
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/P0N9VAScQ36ld3Z80rlj_Q/runs/0/artifacts/public/logs/live_backing.log

---

[task 2020-09-07T16:30:38.499Z] 16:30:38     INFO -  TEST-PASS | xpcshell.ini:toolkit/components/search/tests/xpcshell/test_list_json_locale.js | test_listJSONRegionOverride - [test_listJSONRegionOverride : 82] search initialized - true == true
[task 2020-09-07T16:30:38.500Z] 16:30:38     INFO -  PID 1988 | console.debug: SearchService: "init"
[task 2020-09-07T16:30:38.500Z] 16:30:38     INFO -  PID 1988 | console.debug: SearchService: "getEngines: getting all engines"
[task 2020-09-07T16:30:38.500Z] 16:30:38  WARNING -  TEST-UNEXPECTED-FAIL | xpcshell.ini:toolkit/components/search/tests/xpcshell/test_list_json_locale.js | test_listJSONRegionOverride - [test_listJSONRegionOverride : 85] Should have the correct engine list - ["Test search engine","engine-pref","engine-resourceicon","engine-chromeicon"] deepEqual ["Test search engine","engine-pref","engine-chromeicon"]
[task 2020-09-07T16:30:38.500Z] 16:30:38     INFO -  Z:/task_1599495084/build/tests/xpcshell/tests/toolkit/components/search/tests/xpcshell/test_list_json_locale.js:test_listJSONRegionOverride:85
[task 2020-09-07T16:30:38.500Z] 16:30:38     INFO -  Z:\task_1599495084\build\tests\xpcshell\head.js:_do_main:248
[task 2020-09-07T16:30:38.500Z] 16:30:38     INFO -  Z:\task_1599495084\build\tests\xpcshell\head.js:_execute_test:577
[task 2020-09-07T16:30:38.500Z] 16:30:38     INFO -  -e:null:1
[task 2020-09-07T16:30:38.500Z] 16:30:38     INFO -  exiting test
Bug: Crash in [@ wl_proxy_create_wrapper | libEGL_mesa.so.0@0x236c9] when scrolling
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-09-07 18:00:35+00:00
Resolved: 2020-09-07 20:48:29+00:00

On linux (5.8.1) /mesawith an AMD RX 470, I can reproduce a crash every time I scroll through a heavy page (e.g. twitter) on nightly. Thishappens regardless of the profile in use, but does not happen on stable (80).

This is on wayland but happens even if I don’t set MOZ_ENABLE_WAYLAND to 1, so I assume this is not a factor.

Crash report: https://crash-stats.mozilla.org/report/index/c99b8137-8438-4c71-a2c6-614170200905

Top 10 frames of crashing thread:
```
0 libwayland-client.so.0 wl_proxy_create_wrapper 
1 libEGL_mesa.so.0 libEGL_mesa.so.0@0x236c9 
2 libEGL_mesa.so.0 libEGL_mesa.so.0@0xe6d8 
3 libxul.so mozilla::gl::CreateSurfaceFromNativeWindow gfx/gl/GLContextProviderEGL.cpp:225
4 libxul.so mozilla::gl::GLContextEGL::RenewSurface gfx/gl/GLContextProviderEGL.cpp:517
5 libxul.so mozilla::layers::CompositorBridgeParent::ResumeComposition gfx/layers/ipc/CompositorBridgeParent.cpp:747
6 libxul.so mozilla::layers::CompositorBridgeParent::RecvResumeAsync gfx/layers/ipc/CompositorBridgeParent.cpp:583
7 libxul.so mozilla::layers::PCompositorBridgeParent::OnMessageReceived ipc/ipdl/PCompositorBridgeParent.cpp:1294
8 libxul.so mozilla::layers::PCompositorManagerParent::OnMessageReceived ipc/ipdl/PCompositorManagerParent.cpp:197
9 libxul.so mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2074
```
Bug: Border causes nested <svg> to be cut-off/clipped at some zoom levels
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-09-07 19:58:50+00:00
Resolved: 2020-09-07 20:51:17+00:00

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

Steps to reproduce:

- Have an <svg> element is nested inside another <svg> element.
- Use CSS to set the inner SVG's 'border-width' property to a positive value (1px is enough, and values as small as 0.01px definitely cause this issue as well).
-- The width used affects the "magnitude" of the clipping. A larger value causes more severe clipping, and values over 7px completely hide the inner SVG's contents at all zoom levels in the attached example file.
- Open the document in Firefox
- Zoom in or out and refresh. Try multiple different zoom levels.


Actual results:

 Different zoom levels will have somewhat different clipping amounts, but the clipping always seems to come from the edges of the inner <svg>'s viewbox. The clipping pattern is effectively a rectangle inset of the viewbox.

In my client, at 100% zoom (default) with the html file as-is. there is some clipping but most of the inner-svg's contents are visible. The clipping can be seen in the green squiggly line, which is cut off, despite having the same dimensions and position as the purple squiggly, which is part of the outer-svg. If there were no clipping, the green squiggle should completely overlay the purple. 

If I zoom in and out, the clipping pattern is totally unaffected, until I refresh the page. At different zoom levels, the clipping changes slightly, but does not touch the inner circles. If the border-width is increased to 5px (in the .html file, not in the inspector CSS panel), when opening the file at 100% zoom, the inner-svg is entirely invisible (clipped out), but zooming in and out can make parts of it visible.


Expected results:

The border properties should not affect the rendering of the SVG at all. There should be no border and no clipping. This is the behavior in Edge, Chrome, and IE.
Bug: Intermittent browser/components/newtab/test/browser/browser_asrouter_cfr.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-09-07 22:22:52+00:00
Resolved: 2023-10-13 12:00:47+00:00

**Filed by:** ncsoregi [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer.html#?job_id=315042012&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/EfHfHnyTSVOVYXk7yQN9yg/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/EfHfHnyTSVOVYXk7yQN9yg/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---

>[task 2020-09-07T20:46:45.270Z] 20:46:45     INFO - TEST-PASS | browser/components/newtab/test/browser/browser_asrouter_cfr.js | Should have removed the notification - 0 == 0 - 
[task 2020-09-07T20:46:45.270Z] 20:46:45     INFO - Buffered messages finished
[task 2020-09-07T20:46:45.270Z] 20:46:45     INFO - TEST-UNEXPECTED-FAIL | browser/components/newtab/test/browser/browser_asrouter_cfr.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. - 
[task 2020-09-07T20:46:45.270Z] 20:46:45     INFO - GECKO(2228) | MEMORY STAT vsizeMaxContiguous not supported in this build configuration.
[task 2020-09-07T20:46:45.270Z] 20:46:45     INFO - GECKO(2228) | MEMORY STAT | vsize 7585MB | residentFast 311MB | heapAllocated 135MB
[task 2020-09-07T20:46:45.270Z] 20:46:45     INFO - TEST-OK | browser/components/newtab/test/browser/browser_asrouter_cfr.js | took 66329ms
Bug: Migrating kB to derived keys throws "can't change uid" error
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-09-07 23:21:14+00:00
Resolved: 2020-09-08 09:55:10+00:00

Bug 1426306 introduced a change to the way Account state is stored in Firefox, moving away from storing the root key `kB` and instead storing only some derived keys. From a recent user report, it seems this migration path have and bitrotted; AFAICT it goes like this:

* If we see `kB` in the account state, then `getKeys` will calculate the derived keys and then [call `currentState.updateUserAccountData`](https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/services/fxaccounts/FxAccountsKeys.jsm#84), specifying the current `uid` among the updated fields.
* The [implementation of `AccountState.updateUserAccountData`](https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/services/fxaccounts/FxAccounts.jsm#219) more-or-less directly calls `FxAccountsStorageManager.updateAccountData`.
* The [implementation of `FxAccountsStorageManager.updateAccountData`](https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/services/fxaccounts/FxAccountsStorage.jsm#226) will throw if provided a `uid` field, even if the provided value matches the currently-signed-in-user.

The `FxAccountsInternal` class has a similar `updateUserAccountData` method, but that one [checks for and removes the `uid` field](https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/services/fxaccounts/FxAccounts.jsm#1093). Either the `updateUserAccountData` method on the `AccountState` should do the same, or we should be using the one from `FxAccountsInternal.
Bug: Editing URI in URI bar and pressing Enter goes to search instead of loading new URI
Status: NEW
Priority: P3
Created: 2020-09-08 07:01:44+00:00
Resolved: 2024-05-15 11:48:15+00:00

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

Steps to reproduce:

Browse to a URI on the local network, like
http://myserver/mystuff/ABC-123?
Firefox loads the page directly and displays an abbreviated URI in the location bar:
myserver/mystuff/ABC-123?
Now click in the location bar.  The whole text is selected.  Press right-arrow to clear the selection and put the caret at the end of the text.  Press backspace to delete the final ? character.  The location bar now shows
myserver/mystuff/ABC-123
Press Enter.


Actual results:

Pressing Enter runs a Google search using the edited URI as the search string.


Expected results:

When you've edited a URI and press Enter, it should go to that new URI.  This was always the behaviour of Firefox (and every other browser) in the past.  Editing a URI and then using it as a search string is a rather uncommon operation and should not be the default.

It seems to happen when viewing local network sites that don't have a fully qualified hostname.  I guess there is some guessing of whether the string looks like a URI or looks like a search term.  But Firefox should know that if it's currently showing a page, and the user has edited the URI (not deleted it and pasted in a whole new piece of text), the result of that edit is still a URI.
Bug: Then opening https://www.era.europa.eu/ i get 403 error from cloud front
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-09-08 07:11:26+00:00
Resolved: 2020-10-01 13:12:24+00:00

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

Steps to reproduce:

I opening https://www.era.europa.eu/ web page


Actual results:

I got a 403 error, instead of a web page


Expected results:

We page opened, I tried with chrome and it works
Bug: no proxy settings - policies.json is missing after update
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-09-08 08:54:55+00:00
Resolved: 2020-11-09 16:59:11+00:00

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

Steps to reproduce:

Alway after an update of mozilla firefox on a windows system, are the proxy settings lost. I using the "automatic proxy configuration adress" setting. After the update the field is empty. This problem exists since more versions. 


Actual results:

no proxy settings


Expected results:

proxy settings should be stay
Bug: The media tab in page info displays incorrect file sizes
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-09-08 10:10:11+00:00
Resolved: 2023-04-11 10:14:52+00:00

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

Steps to reproduce:

1. Load http://www.museen-nord.de/Objekt/DE-MUS-044713/lido/dc00000232
2. Right-click and choose "View Page Info"
3. Select the "Media" tab.
4. Sort the media by size by clicking on the "size" column header.


Actual results:

The media are not sorted by size. Several images are listed as having a "0 byte" size.




Expected results:

The sort order should be correct, and images should not have a 0 byte size.