av9ash/GitBugs huggingface dataset:
Bug: FF 89.0.1 regression bug on login page
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-20 07:33:30+00:00
Resolved: 2021-06-20 07:37:56+00:00

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

Steps to reproduce:

I am subscribed to an online newspaper www.repubblica.it
Login page is in the right-top corner under "ACCEDI" (login); site is slow and the login button appears after 10-15 seconds.

Click on that button and you are served with a login page (full of trackers as usual, but I digress).

Now all worked in FF 89 and lower. FF 89.0.1 makes the page wait indefinitely (even in safe mode).

Latest FF Nightly 91.0a1 (2021-06-19) (64-bit) --- works.

See attached hardcopies.




Actual results:

I disabled all tracking protection and tried also network.cookie.sameSite.laxByDefault by setting it to true.

Site spews a lot of messages on console and doesn't work (works in Chrome though):

Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘https://cdns.eu1.gigya.com’) does not match the recipient window’s origin (‘https://quotidiano.repubblica.it’).
Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘https://253822047730481.mateti.net’) does not match the recipient window’s origin (‘https://quotidiano.repubblica.it’).




Expected results:

See attached files. Login forms is shown on FF nightly/Chrome; not shown in FF 89.0.1.
Bug: Titlebar color doesn't change with focus change
Status: NEW
Priority: --
Created: 2021-06-20 10:56:21+00:00
Resolved: 2021-06-23 11:32:40+00:00

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

Steps to reproduce:

Automatic upgrade to 89 causes regression of titlebar focus color


Actual results:

Titlebar remains same color in focus and out of focus.


Expected results:

Titlebar changes colors to denote focus state.
Bug: Data download bug
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-20 14:58:46+00:00
Resolved: 2021-06-22 14:05:33+00:00

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

Steps to reproduce:

Downloading any file can fail the larger the file the less likely the file will download.  


Actual results:

I tried to download on Firefox and retried about 20 times.  I used Chrome and the file downloaded first time.  I think there is a bug in the processing of data as it comes down.


Expected results:

Work first time.
Bug: Restoring previous session after clearing history.
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-20 17:29:39+00:00
Resolved: 2024-07-01 15:51:44+00:00

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

Steps to reproduce:

Default stngs. Open some tabs. Ctrl+Shift+Del (all marks checked), OK. Close browser. Open browser. Menu>Restore previous session. Tabs are back.


Actual results:

The tabs that opened at the moment of clearing the history can be restored. History not cleared. Old one. Seen in 40-50+.


Expected results:

Guess data should be all gone.
Bug: v89,0 tabs are no longer connected to the page being displayed
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-20 19:02:39+00:00
Resolved: 2021-06-21 13:15:50+00:00

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

Steps to reproduce:

Upgraded to v89.0 using the OS package manager
  OS/Distro: Linux Mint 20,
  Package   : firefox 89.0+linuxmint1+ulyssa 


Actual results:

When using tabs, the tab selector/indicator is now disassociated from the tabbed page.  Any additional UI bars, e.g the URL bar or the Bookmarks Toolbar now appear between the tabs and the pages they represent thus breaking the visual connection between the two.



Expected results:

As with the previous version, tabs should be contiguous with the pages the indicate/select.  It appears this may have been an intentional change.  if so there is still a bug as there is no mechanism to restore the previous function.
Bug: Content not displayed on diariomotor website
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-20 23:33:28+00:00
Resolved: 2021-06-22 11:00:28+00:00

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

Steps to reproduce:

On this url some content is not displayed:
https://www.diariomotor.com/noticia/beeline-velo-2-gadget-bicicleta/
Bug: Bookmarks are being deleted when computer restarts
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-20 23:35:42+00:00
Resolved: 2021-11-12 03:30:17+00:00

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

Steps to reproduce:

1. Create a bunch of bookmarks folders.
2. Add several bookmark URLs to a bookmark folder
3. Restart computer without closing Firefox


Actual results:

After restarting my computer, Firefox will reverse all bookmarks that I have created in that session. Any links or bookmark folders I will have created are gone and the bookmark bar is reverted back to the previous state before I launched the new browsing session.

I have also checked on my phone and it reverts the bookmarks there as well. 


Expected results:

Firefox should be saving these bookmarks even when I need to restart my computer unexpectedly. I should not have to close all windows for the bookmarks to save.
Bug: Web search on home screen issue
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-06-21 01:33:41+00:00
Resolved: 2021-06-21 15:19:22+00:00

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

Steps to reproduce:

On the home screen, enter text in the web search box.


Actual results:

The text does not appear in the web search box - but instead appears in the URL bar at the top.


Expected results:

The text should stay in the web search box until the user hits return.

This is causing  all sorts of confusion. I never search in the URL bar, and would like this reverted to it's previous state (mentioned above).
Bug: Bookmark sub-menu remains open after clicking on a Bookmark in the Bookmark menu if an attempt to drag & drop a Bookmark into it was cancelled.
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-06-21 06:16:57+00:00
Resolved: 2023-12-27 07:25:41+00:00

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

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.8

If the user attempts to move a Bookmark to a sub menu (folder) using drag & drop
and the drop down Bookmark menu, but instead cancels it by moving the mouse back
into the Bookmark menu and releasing the button, and then clicks on any bookmark
before the sub menu (folder) closes, the sub menu (folder) will stay open.

Reproducible: Always
Steps to Reproduce:
1. Create a Bookmark and a Folder.
2. Open the Bookmarks menu.
3. Click and hold on the Bookmark to begin the drag & drop procedure.
4. Drag the Bookmark into the created Folder, but do not drop it there.  This
will open a sub-menu containing the Bookmarks, if any, in the Folder.
5. Drag the Bookmark back to its original location.
6. Quickly drop the Bookmark and click any Bookmark before the Folder sub-menu
closes.
Actual Results:  
The Folder sub-menu will remain open even though the Bookmarks menu is closed.

Expected Results:  
The Folder sub-menu should have closed with the rest of the Bookmark menu.

This occurs with both the Default theme and the Luna theme.

It is (relatively easily) avoided by waiting until the Folder menu closes before
clicking on a Bookmark.
Bug: Bookmark sub-menu remains open after clicking on a Bookmark in the Bookmark menu if an attempt to drag & drop a Bookmark into it was cancelled.
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2021-06-21 06:22:29+00:00
Resolved: 2021-06-21 06:22:57+00:00

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

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

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.8

If the user attempts to move a Bookmark to a sub menu (folder) using drag & drop
and the drop down Bookmark menu, but instead cancels it by moving the mouse back
into the Bookmark menu and releasing the button, and then clicks on any bookmark
before the sub menu (folder) closes, the sub menu (folder) will stay open.

Reproducible: Always
Steps to Reproduce:
1. Create a Bookmark and a Folder.
2. Open the Bookmarks menu.
3. Click and hold on the Bookmark to begin the drag & drop procedure.
4. Drag the Bookmark into the created Folder, but do not drop it there.  This
will open a sub-menu containing the Bookmarks, if any, in the Folder.
5. Drag the Bookmark back to its original location.
6. Quickly drop the Bookmark and click any Bookmark before the Folder sub-menu
closes.
Actual Results:  
The Folder sub-menu will remain open even though the Bookmarks menu is closed.

Expected Results:  
The Folder sub-menu should have closed with the rest of the Bookmark menu.

This occurs with both the Default theme and the Luna theme.

It is (relatively easily) avoided by waiting until the Folder menu closes before
clicking on a Bookmark.
Bug: Page number on the top right of the form is not shown
Status: NEW
Priority: P3
Created: 2021-06-21 07:29:25+00:00
Resolved: 2022-02-18 16:00:10+00:00

https://web.archive.org/web/20201111224144/https://www.canada.ca/content/dam/ircc/migration/ircc/english/pdf/kits/forms/imm1344e.pdf

E.g. on the first page, it should read "Page 1 of 7".
Bug: "validated" text should be centered
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-06-21 07:30:00+00:00
Resolved: 2021-06-25 10:02:56+00:00

On the first page of https://web.archive.org/web/20201111224144/https://www.canada.ca/content/dam/ircc/migration/ircc/english/pdf/kits/forms/imm1344e.pdf, the "validated" text should be centered.
Bug: "validated" field should not be highlighted
Status: VERIFIED
Priority: P1
Resolution: FIXED
Created: 2021-06-21 07:31:10+00:00
Resolved: 2021-07-09 12:33:22+00:00

It is marked as "Office use only", and IDK how Master PDF Editor is able to highlight all the fields except this one. Maybe there is some kind of marker in the field that says it shouldn't be highlighted?

The PDF is https://web.archive.org/web/20201111224144/https://www.canada.ca/content/dam/ircc/migration/ircc/english/pdf/kits/forms/imm1344e.pdf.
Bug: Loading a non-http page (e.g. about: page) after a normal web page still updates the interaction for the web page
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2021-06-21 12:01:31+00:00
Resolved: 2021-06-21 21:40:14+00:00

STR

1. Turn on interaction recording and logging and restart Firefox
2. Navigate to a normal web page, wait a little bit.
3. In the same tab, type about:support.
4. Wait a little bit more, then switch to a different window or application.

Actual Results

At step 3, the console did not indicate the end of interaction for the web page. It also logs an updated for it when step 4 switches elsewhere.

Expected Results

The interaction for the original web page should be stopped at step 3, and no more updates for that interaction received, unless the web page is navigated to in future.
Bug: Automatic change of "sizemode" from "maximized" to "normal" in xulstore.json
Status: UNCONFIRMED
Priority: --
Created: 2021-06-21 16:05:35+00:00
Resolved: 2021-07-12 09:39:58+00:00

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

Steps to reproduce:

The problem occurs under Windows 10, whenever I change from another program (not Firefox) in "maximized" mode to Firefox, which I left in maximized mode.


Actual results:

The Firefox window automatically changes to "normal" mode (i.e., a resizable window). The xulstore.json adapts correspondingly.
The bug can be temporarily removed by deleting the xulstore.json file. However, it re-occurs as Firefox re-creates the xulstore file.
Denying Firefox writing access to the xulstore file doesn't work either, as another temporary version of the xulstore file is created.


Expected results:

Firefox should have stayed in "maximized" mode.
Bug: Intermittent [tier2] browser/base/content/test/contextMenu/browser_view_image.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-06-21 17:25:37+00:00
Resolved: 2022-04-19 17:05:35+00:00

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

---
```
[task 2021-06-21T15:57:10.603Z] 15:57:10     INFO - TEST-PASS | browser/base/content/test/contextMenu/browser_view_image.js | tab - Should have loaded image. - 2 == true - 
[task 2021-06-21T15:57:10.603Z] 15:57:10     INFO - TEST-PASS | browser/base/content/test/contextMenu/browser_view_image.js | window - checking if popup is closed - 
[task 2021-06-21T15:57:10.603Z] 15:57:10     INFO - window - Popup Shown
[task 2021-06-21T15:57:10.603Z] 15:57:10     INFO - Buffered messages finished
[task 2021-06-21T15:57:10.604Z] 15:57:10     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/contextMenu/browser_view_image.js | Test timed out - 
[task 2021-06-21T15:57:10.604Z] 15:57:10     INFO - Not taking screenshot here: see the one that was previously logged
[task 2021-06-21T15:57:10.604Z] 15:57:10     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/contextMenu/browser_view_image.js | Uncaught exception received from previously timed out test - popuphidden listener on #contentAreaContextMenu not removed before the end of test
[task 2021-06-21T15:57:10.605Z] 15:57:10     INFO - GECKO(1540) | MEMORY STAT | vsize 16191MB | residentFast 354MB | heapAllocated 105MB
[task 2021-06-21T15:57:10.605Z] 15:57:10     INFO - TEST-OK | browser/base/content/test/contextMenu/browser_view_image.js | took 45095ms
```
Bug: save to pocket icon highlighted for other tabs
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2021-06-21 18:34:52+00:00
Resolved: 2021-09-20 12:52:12+00:00

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

Steps to reproduce:

Open multiple tabs.  Click "add to pocket" icon on one tab.  


Actual results:

The save to pocket icon is highlighted on all of the other open tabs.


Expected results:

The save to pocket icon should NOT be highlighted on all of the other open tabs.
Bug: firefox identifies itself as chrome
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-06-21 18:45:04+00:00
Resolved: 2021-06-21 18:58:22+00:00

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

Steps to reproduce:

click on the three lines then more tools then task manager right click on the task manager icon then open image in new tab then it says chrome: //global/skin/icons/performance.svg


Actual results:

it said chrome instead of firefox


Expected results:

it would be better if it said firefox://global/skin/icons/performance.svg
Bug: closes open tabs
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-06-21 20:10:53+00:00
Resolved: 2021-12-31 12:08:49+00:00

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

Steps to reproduce:

I launch the browser a couple of minutes after closing


Actual results:

sometimes after restarting firefox closes previously opened tabs, although in the settings it is worth opening tabs from the previous session at startup


Expected results:

open tabs from previous session
Bug: Crash in [@ mozilla::dom::SessionStoreDataCollector::CollectSessionStoreData]
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-06-21 20:17:08+00:00
Resolved: 2021-06-25 19:03:36+00:00

Maybe Fission related. (DOMFissionEnabled=1)

Looks like this showed up in the 20210616214200 build. All of the non-beta crashes have Fission enabled.


Crash report: https://crash-stats.mozilla.org/report/index/008e88c8-f422-4820-a53c-4c6470210620

MOZ_CRASH Reason: ```MOZ_DIAGNOSTIC_ASSERT(listener->mTimer)```

Top 10 frames of crashing thread:
```
0 libxul.so mozilla::dom::SessionStoreDataCollector::CollectSessionStoreData toolkit/components/sessionstore/SessionStoreDataCollector.cpp:51
1 libxul.so mozilla::dom::SessionStoreChangeListener::HandleEvent toolkit/components/sessionstore/SessionStoreChangeListener.cpp:92
2 libxul.so {virtual override thunk} 
3 libxul.so mozilla::EventListenerManager::HandleEventInternal dom/events/EventListenerManager.cpp:1306
4 libxul.so mozilla::EventTargetChainItem::HandleEventTargetChain dom/events/EventDispatcher.cpp:593
5 libxul.so mozilla::EventTargetChainItem::HandleEventTargetChain dom/events/EventDispatcher.cpp:637
6 libxul.so mozilla::EventDispatcher::Dispatch dom/events/EventDispatcher.cpp:1116
7 libxul.so mozilla::dom::VisualViewport::FireScrollEvent dom/base/VisualViewport.cpp:299
8 libxul.so mozilla::dom::VisualViewport::VisualViewportScrollEvent::Run dom/base/VisualViewport.cpp:280
9 libxul.so nsRefreshDriver::Tick layout/base/nsRefreshDriver.cpp:2274
```
Bug: Cannot use Firefox for Bugzilla
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-06-21 20:34:14+00:00
Resolved: 2021-07-08 07:16:41+00:00

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

Steps to reproduce:

I was trying to report pervasive problems I have encountered with Firefox over the last couple of months, on many websites, most often when trying to set their privacy settings.  This often includes buttons not displaying properly, checkboxes not working, buttons not working.
To be specific.  I tried to end a bug in mozilla using Firefox.  Firstly, I had to use another browser to set up my account because I could not select a checkbox to say I had read the conditions to set up an accont in Firefox.
I then tried to submit a bug using Firefox and that failed, again because of a checkbox not working issue.  



Actual results:

The checkbox didn't work when setting up my bugzilla account.
The checkbox didn't work when submitting my bug
I couldn't submit my bug when using:
    https://bugzilla.mozilla.org/enter_bug.cgi#h=bugForm%7CFirefox
I'm trying again.



Expected results:

Should have checked the checkbox and submitted the bug report.
Bug: Intermittent browser/components/places/tests/browser/interactions/browser_interactions_view_time.js | Uncaught exception - Should have saved to the database - timed out after 50 tries.
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-06-21 21:22:58+00:00
Resolved: 2021-07-20 17:04:22+00:00

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

---
```
[task 2021-06-21T20:30:55.038Z] 20:30:55     INFO - TEST-PASS | browser/components/places/tests/browser/interactions/browser_interactions_view_time.js | Should have saved the page into the database - "https://example.com/" == "https://example.com/" - 
[task 2021-06-21T20:30:55.039Z] 20:30:55     INFO - TEST-PASS | browser/components/places/tests/browser/interactions/browser_interactions_view_time.js | Should have kept the exact time - 10494.829899 == 10494.829899 - 
[task 2021-06-21T20:30:55.039Z] 20:30:55     INFO - Switch back to new window
[task 2021-06-21T20:30:55.039Z] 20:30:55     INFO - Buffered messages finished
[task 2021-06-21T20:30:55.039Z] 20:30:55     INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/browser/interactions/browser_interactions_view_time.js | Uncaught exception - Should have saved to the database - timed out after 50 tries.
[task 2021-06-21T20:30:55.040Z] 20:30:55     INFO - Leaving test bound test_interactions_private_browsing
[task 2021-06-21T20:30:55.040Z] 20:30:55     INFO - Entering test bound test_interactions_idle
[task 2021-06-21T20:30:55.040Z] 20:30:55     INFO - GECKO(20440) | console.debug: InteractionsManager: "idle"
[task 2021-06-21T20:30:55.040Z] 20:30:55     INFO - GECKO(20440) | console.debug: InteractionsManager: "No update due to no active window"
[task 2021-06-21T20:30:59.987Z] 20:30:59     INFO - Not taking screenshot here: see the one that was previously logged
[task 2021-06-21T20:30:59.988Z] 20:30:59     INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/browser/interactions/browser_interactions_view_time.js | Uncaught exception - Should have saved to the database - timed out after 50 tries.
[task 2021-06-21T20:30:59.989Z] 20:30:59     INFO - Leaving test bound test_interactions_idle
[task 2021-06-21T20:30:59.993Z] 20:30:59     INFO - GECKO(20440) | MEMORY STAT | vsize 3480MB | residentFast 411MB | heapAllocated 144MB
[task 2021-06-21T20:30:59.994Z] 20:30:59     INFO - TEST-OK | browser/components/places/tests/browser/interactions/browser_interactions_view_time.js | took 16625ms
```
Bug: Intermittent browser/components/preferences/tests/browser_subdialogs.js | Test timed out -
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2021-06-21 21:46:40+00:00
Resolved: 2022-07-27 18:36:59+00:00

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

---
```
[task 2021-06-21T20:57:39.968Z] 20:57:39     INFO - TEST-PASS | browser/components/preferences/tests/browser_subdialogs.js | dialog count should decrease by 1 - 0 == 0 - 
[task 2021-06-21T20:57:39.969Z] 20:57:39     INFO - TEST-PASS | browser/components/preferences/tests/browser_subdialogs.js | stack children count should decrease by 1 - 1 == 1 - 
[task 2021-06-21T20:57:39.970Z] 20:57:39     INFO - Leaving test bound check_opening_while_closing
[task 2021-06-21T20:57:39.970Z] 20:57:39     INFO - Entering test bound window_close_on_dialog
[task 2021-06-21T20:57:39.971Z] 20:57:39     INFO - waiting for subdialog DOMFrameContentLoaded
[task 2021-06-21T20:57:39.971Z] 20:57:39     INFO - Buffered messages finished
[task 2021-06-21T20:57:39.972Z] 20:57:39     INFO - TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_subdialogs.js | Test timed out - 
[task 2021-06-21T20:57:39.973Z] 20:57:39     INFO - GECKO(1124) | MEMORY STAT | vsize 1821MB | vsizeMaxContiguous 9MB | residentFast 804MB | heapAllocated 550MB
[task 2021-06-21T20:57:39.973Z] 20:57:39     INFO - TEST-OK | browser/components/preferences/tests/browser_subdialogs.js | took 45055ms
```
Bug: fillable pdf form entries are not stored correctly
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-06-22 08:11:15+00:00
Resolved: 2021-06-23 07:14:02+00:00

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

Steps to reproduce:

i created a fillable pdf with wkhtmltopdf, with a simple name, surname form. that pdf is opened with firefox, i can edit the form fields, entered some entries and save it under a new name. i openend the new file and all form fields are emtpy.

This works with microsoft edge browser. 

if i save the pdf with edge i see the changed forms fields with firefox.
if i save the pdf with firefox i cant see the form fields values in firefox and edge.



Actual results:

form fields data was not saved into pdf


Expected results:

form fields filled with data