av9ash/GitBugs huggingface dataset:
Bug: Incorrect rendering in Firefox PDF viewer
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-07-14 00:56:01+00:00
Resolved: 2021-07-28 07:32:48+00:00

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

Steps to reproduce:

Recent update to Firefox v.90 (as well as in FF dev. edition v.91) caused an issue to show all check boxes are CHECKED by default in built-in FF PDF viewer.


Actual results:

 The PDF doc was generated programmatically on webserver side based on a blank PDF doc with acrofields (template). The result is absolutely all check boxes and radio buttons are checked by default giving a corrupted output, supposedly a built-in pdf.js is changed as well.


Expected results:

Normally those check boxes should be unmarked (non-checked). Such issue never happened in earlier versions of FF. The built-in PDF output is normal in Google Chrome and MS Edge browsers. Please see screenshots in attachment.
Bug: browser.urlbar.clickSelectsAll=false option removed
Status: VERIFIED
Priority: --
Resolution: DUPLICATE
Created: 2021-07-14 02:47:25+00:00
Resolved: 2021-07-14 09:32:48+00:00

Yes, this is a duplicate of #1621570, a bug that has over 100 comments and (as of right now) 143 votes. But, being that it's closed as WONTFIX, I suspect that it's generally not on your radar. It was closed before I could chime in back then, but I wanted to give a bit of a retrospective at this point.

There's lots of changes that one hates initially but grows to like over time. The behaviour brought about by #1621570 is definitely not one of them for me though. It has been over a year and I have yet to find a single upside to that change, it is just strictly worse. There are two primary problems with it, namely:

1) Editing URLs
2) Copying URLs

Editing a URL means clicking once, waiting, clicking again and then finally starting your edit. This is a very common operation and is slowed down non-trivially. If you accidentally double click instead of single click twice, your paste buffer gets mangled (which quite frequently contained what you wanted to put into the URL) and you get to start all over. Speaking of paste buffers, it's not possible to simply paste your URL fragment into the address bar in the correct location with a single middle click either, because that replaces the entire URL now.

Secondly, the least painful way to copy URLs now is to double click and drag from the beginning to the end of the URL. There are a number of problems with this. For example, you may miss double clicking the http(s) in the URL (and so miss the beginning of the URL in your copy). For longer URLs, the http(s) may not even be in view, so you need to scroll over first. Also it's easy to accidentally not select all the way to the end of the URL, particularly for URLs long enough to require scrolling, resulting in copying the wrong thing.

Yes, I know triple clicking is an option too but that's just such an unusual motion. I don't use it for anything else and find it jarring to have to use it for this one oddball input field. Double click and drag (separately) are at least common motions.

Yes, I understand you want to lower your maintenance burden, I'm a developer too, I get it. But also as a developer, I both edit and copy URLs in the URL bar quite frequently, and this is a consistently infuriating process since Firefox 75. It would be really great if you would reconsider the decision to kill the browser.urlbar.clickSelectsAll option.
Bug: 3.07 - 3.06% outlook dcf / outlook dcf (Linux) regression on Wed July 7 2021
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-07-14 06:34:13+00:00
Resolved: 2022-07-28 13:29:48+00:00

Perfherder has detected a browsertime performance regression from push [739435aeeb7e4f8151a9edba45c0ea23531f3e1e](https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=739435aeeb7e4f8151a9edba45c0ea23531f3e1e). As author of one of the patches included in that push, we need your help to address this regression.

### Regressions:

| **Ratio** | **Suite** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--|--| 
| 3% | outlook | dcf | linux1804-64-shippable-qr | cold webrender | 275.38 -> 283.83 |
| 3% | outlook | dcf | linux1804-64-shippable-qr | cold webrender | [274.96](https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/W0OzqjIcTHSdOQz7ygwjEA/runs/0/artifacts/public/test_info/browsertime-results.tgz) -> [283.38](https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HQ5LGmbgSAq7cLUngxjRXA/runs/0/artifacts/public/test_info/browsertime-results.tgz) |
### Improvements:

| **Ratio** | **Suite** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**| 
|--|--|--|--|--|--| 
| 15% | youtube | SpeedIndex | windows10-64-shippable-qr | warm webrender | 934.92 -> 797.67 |


Details of the alert can be found in the [alert summary](https://treeherder.mozilla.org/perfherder/alerts?id=30564), including links to graphs and comparisons for each of the affected tests. Please follow our [guide to handling regression bugs](https://wiki.mozilla.org/TestEngineering/Performance/Handling_regression_bugs) and **let us know your plans within 3 business days, or the offending patch(es) will be backed out** in accordance with our [regression policy](https://www.mozilla.org/en-US/about/governance/policies/regressions/).

For more information on performance sheriffing please see our [FAQ](https://wiki.mozilla.org/TestEngineering/Performance/FAQ).
Bug: browser.proton.* should disable all new look on firefox since 89
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2021-07-14 09:56:15+00:00
Resolved: 2021-09-05 15:52:19+00:00

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

Steps to reproduce:

Firefox has very, very ugly look. Firefox since 89 absolutely unusable. I am using 88 version and will use it some years. I seriously consider to migrate to something other, for example, palemoon browser.


Actual results:

Firefox has options to disable new look "browser.proton.enabled" and "browser.proton.modals.enabled" but it does not disable all new look.


Expected results:

browser.proton.enabled and browser.proton.modals.enabled should disable:
- Annoying dark main window for ALL modal dialogs.
  Currently it restores normal dialog only for editing bookmark. It is not restore dialog for confirmation closing multiple tabs, all modal dialogs in settings page, confirmation for default browser.

- All buttons on all dialogs should be from system theme (not simple rectangles when can't understand it is button or not)

- All scrollbars should be from system theme
Bug: Favicon missing for bookmark even though tab shows a favicon
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-07-14 10:39:13+00:00
Resolved: 2021-07-14 13:52:24+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 added a bookmark on the BookMarks Toolbar to the following page:

https://online.macquarie.com.au/personal/#/


Actual results:

When the website is visited, the tab in Firefox shows a favicon, but the bookmark does not. Usually clicking on the bookmark refreshes the icon, but not in this case.


Expected results:

The bookmark should have the same favicon as the tab when the website is visited.

I tested it in Chrome and Brave, and both of them show the bookmark icon correctly.
Bug: The "Learn more about Firefox Suggest" button wrongly redirects to "Sponsored tiles on the New Tab" page
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-07-14 12:00:18+00:00
Resolved: 2021-07-22 08:48:01+00:00

**[Affected Versions]:**
- Firefox Release 90 (Build ID: 20210705185941)
- Firefox Beta 91.0b1 (Build ID: 20210712122804)
- Firefox Nightly 92.0a1 (Build ID: 20210713214232) 

**[Affected Platforms]:**
- Windows 10 x64
- macOS 10.15.7
- Linux Mint 20

**[Prerequisites]:**
- Have Firefox Release 90 installed.
- Have the ESET Antivirus solution installed.
- Have the “browser.search.region” set to “US.
- Have the following prefs set:
 - "browser.urlbar.quicksuggest.enabled" = "true";
 - "browser.urlbar.quicksuggest.ShouldShowOnboardingDialog" = "false";

**[Steps to reproduce]:**
1. Open the Firefox browser with the profile from prerequisites.
2. Open a New Tab page, type the "nike" keyword in the "Awesome bar".
3. Click the "Learn more about Firefox Suggest" button from the right part of the sponsored suggestion displayed.
4. Observe the opened page.

**[Expected results]:**
- A support page with more details about Firefox Suggest is displayed.
    
**[Actual results]:**
- The "Sponsored tiles on the New Tab" page is opened and there is no mention about Firefox Suggest.

**[Notes]:**
- The same behavior can be also observed for the "Learn more about Firefox Suggest" link from the "about:preferences#search" page.
- Attached is a screen recording of the issue.
Bug: Nightly 92 not honouring browser.proton.enabled false
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-07-14 12:43:30+00:00
Resolved: 2021-07-14 13:49:37+00:00

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

Steps to reproduce:

Changed browser.proton.enabled value from true to false to get tab style back to FF88 style (i.e. with dividers, and better visibility).


Actual results:

Tab UI look and feel was still "proton" style (floating tabs and no dividers)..


Expected results:

Expected to get tab dividers and better visibility.
Bug: The Firefox Suggest label is not read by screenreaders if the section only contains a Sponsored result
Status: VERIFIED
Priority: P2
Resolution: FIXED
Created: 2021-07-14 14:17:29+00:00
Resolved: 2023-06-02 15:21:46+00:00

**[Affected Versions]:**
- Firefox 89.0.2 (Build ID: 20210622155641)
- Firefox 90.0 (Build ID: 20210705185941)
- Firefox 91.0b2 (Build ID: 20210713163746) (channel changed to release)
- Firefox 92.0a1 (Build ID:20210714093409) (channel changed to release)

**[Affected Platforms]:**
- Windows 10
- Linux Mint 20
- macOS 10.15.7

**[Prerequisites]:**
- Have a screen reader turned on (e.g. Orca).
- Be enrolled in the History vs Offline Firefox Suggest experiment ([user.js](https://drive.google.com/file/d/15htkWM4romS5Oxbq1dlvdf8ZnYgTpNBY/view?usp=sharing) used) - requires “browser.search.region” set to “US”. 

**[Steps to reproduce]:**
1. Open the Firefox browser with the profile from prerequisites.
2. Focus the address bar and enter a string that will only display a Sponsored result in the Firefox Suggest section (e.g. “nike”).
3. Use the keyboard to focus the Sponsored result.

**[Expected result]:**
- When the Sponsored result is focused, the “Firefox Suggest” label is read first.

**[Actual result]:**
- The “Firefox Suggest” label is not read at all if only a Sponsored result is displayed in the Firefox Suggest list.

**[Notes]:**
- Attached is a [recording](https://drive.google.com/file/d/1z9bU6yT4GEcQN7YLXZmeMEfsbZ63kLAJ/view?usp=sharing) of the issue.
Bug: [Mac] Tab navigation skips certain elements (inside bookmark panel or about: preferences page)
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2021-07-14 14:56:50+00:00
Resolved: 2021-07-21 21:43:48+00:00

**Affected versions**
- 92.0a1 (2021-07-13)
- 91.0b1
- 90.0

**Affected platforms**
- macOS 10.13
- macOS 12.0 (beta build 21A5268h)

**Unaffected platforms**
- macOS 11.0

**Steps to reproduce**
1. Open the “Bookmark this page” panel (star icon)
2. Navigate the panel using the Tab key 
3. Observe the highlight focus


**Expected result**
- All fields and buttons can be navigated using the Tab key

**Actual result**
- Only the input fields can be navigated 

**Regression range**
- n/a; seams to be system version related rather than Firefox one 

**Other notes**
- The issue can be observed also inside about:preferences where checkboxes are skipped when navigating.
Bug: [linux, theme-specific] Menu Bar is unreadable in Firefox 90 (dark text on a dark background) with clearlooks-phenix gtk theme and builtin Firefox dark theme
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-07-14 16:26:59+00:00
Resolved: 2021-07-21 12:32:53+00:00

The text in the menu bar in Firefox 90 does not follow the theme anymore, but is black.

Steps to reproduce:
- Install Firefox 89
- Enable the menu bar
- Use the dark theme
- Verify that the menu bar has white text
- Upgrade to Firefox 90
- See that the menu bar has black text on a dark background

Expected result:
The text color should come from the theme (and be white)

Observed result:
The text color is black
Bug: Intermittent browser/components/downloads/test/browser/browser_downloads_panel_context_menu.js | uncaught exception - TypeError: event.target.hidePopup is not a function at onmouseout/gCustomizeMode._downloadPanelAutoHideTimeout<@chrome://browser/content
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-07-14 17:52:01+00:00
Resolved: 2021-08-17 17:01:25+00:00

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

---
```
[task 2021-07-14T16:34:10.328Z] 16:34:10     INFO - TEST-PASS | browser/components/downloads/test/browser/browser_downloads_panel_context_menu.js | Item at 4 matches expected selector: [command="downloadsCmd_clearList"] - 
[task 2021-07-14T16:34:10.329Z] 16:34:10     INFO - Buffered messages finished
[task 2021-07-14T16:34:10.329Z] 16:34:10     INFO - TEST-UNEXPECTED-FAIL | browser/components/downloads/test/browser/browser_downloads_panel_context_menu.js | uncaught exception - TypeError: event.target.hidePopup is not a function at onmouseout/gCustomizeMode._downloadPanelAutoHideTimeout<@chrome://browser/content/browser.xhtml:1:78
[task 2021-07-14T16:34:10.329Z] 16:34:10     INFO - 
[task 2021-07-14T16:34:10.329Z] 16:34:10     INFO - Stack trace:
[task 2021-07-14T16:34:10.330Z] 16:34:10     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:simpletestOnerror:1964
[task 2021-07-14T16:34:10.330Z] 16:34:10     INFO - GECKO(3976) | JavaScript error: chrome://browser/content/browser.xhtml, line 1: TypeError: event.target.hidePopup is not a function
[task 2021-07-14T16:34:10.331Z] 16:34:10     INFO - TEST-PASS | browser/components/downloads/test/browser/browser_downloads_panel_context_menu.js | Expected no errors verifying context menu items - 
[task 2021-07-14T16:34:10.331Z] 16:34:10     INFO - Leaving test bound Canceled PDF download
[task 2021-07-14T16:34:10.332Z] 16:34:10     INFO - Console message: [JavaScript Error: "TypeError: event.target.hidePopup is not a function" {file: "chrome://browser/content/browser.xhtml" line: 1}]
[task 2021-07-14T16:34:10.332Z] 16:34:10     INFO - onmouseout/gCustomizeMode._downloadPanelAutoHideTimeout<@chrome://browser/content/browser.xhtml:1:78
[task 2021-07-14T16:34:10.332Z] 16:34:10     INFO - 
[task 2021-07-14T16:34:10.332Z] 16:34:10     INFO - GECKO(3976) | MEMORY STAT | vsize 8060MB | residentFast 405MB | heapAllocated 174MB
[task 2021-07-14T16:34:10.333Z] 16:34:10     INFO - TEST-OK | browser/components/downloads/test/browser/browser_downloads_panel_context_menu.js | took 950ms
```
Bug: Clean up styles in the Bookmarks Menu Button menupopups on Windows 7 and 10
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2021-07-14 18:08:59+00:00
Resolved: 2021-08-04 11:57:50+00:00

The Bookmarks Menu Button menupopup has labels that aren't aligned properly - they have the menuitem-iconic class on them, which indents the labels for icons that aren't there. They also inherit some Windows-specific styles from menu.css which break alignment a bit.

The screenshot tries to illustrate what I'm seeing on Windows 7. Similar issues exist on Windows 10.
Bug: Intermittent TV browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and selection changed - cut - Got true, expected false
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2021-07-14 20:27:47+00:00
Resolved: 2021-08-10 17:01:38+00:00

**Filed by:** ncsoregi [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=345209812&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/B0XG9u1CRDmCB9tQohYM2w/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/B0XG9u1CRDmCB9tQohYM2w/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2021-07-14T16:09:45.453Z] 16:09:45     INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and visible - paste - 
[task 2021-07-14T16:09:45.453Z] 16:09:45     INFO - Buffered messages finished
[task 2021-07-14T16:09:45.454Z] 16:09:45     INFO - TEST-UNEXPECTED-FAIL | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and selection changed - cut - Got true, expected false
[task 2021-07-14T16:09:45.455Z] 16:09:45     INFO - Stack trace:
[task 2021-07-14T16:09:45.456Z] 16:09:45     INFO - chrome://mochikit/content/browser-test.js:test_is:1354
[task 2021-07-14T16:09:45.456Z] 16:09:45     INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_editcontrols_update.js:checkState:9
[task 2021-07-14T16:09:45.457Z] 16:09:45     INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_editcontrols_update.js:test_panelui_opened:119
[task 2021-07-14T16:09:45.458Z] 16:09:45     INFO - TEST-PASS | browser/components/customizableui/test/browser_editcontrols_update.js | Update when edit-controls is on panel and selection changed - paste - 
```
Bug: Pocket "saved" icon and menu persist incorrectly when tab is switched
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2021-07-14 21:15:50+00:00
Resolved: 2021-07-15 10:57:04+00:00

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

Steps to reproduce:

1. Click Save to Pocket
2. ctrl+tab to go to the next tab


Actual results:

- Saved icon persists (red and filled-in), even if (as is usually the case) the next tab is not saved to pocket
- Dropdown menu also does not disappear when tab is switched, so it looks like it's for the new tab but really it references the tab that was just switched away from

Note: this doesn't repro if the Pocket menu is dismissed before switching tabs.  In that case the black-and-white "unsaved" pocket icon will correctly show after tab switching

Also does not repro if a different tab is *clicked*, only on keyboard navigate to new tab.


Expected results:

When switching tabs, the Pocket icon should always reflect whether the *current* tab has been saved, not the tab I just switched away from
Bug: Doesn't display a part of a page
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2021-07-14 21:42:00+00:00
Resolved: 2021-08-09 22:01:19+00:00

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

Steps to reproduce:

1) Go to this page https://www.novinky.cz/domaci/diskuze/striz-chce-vedet-do-kdy-verejny-zalobce-rozhodne-o-kauze-capi-hnizdo-40366246

2) it should feature a discussion forum below "Zpět na článek"



Actual results:

The discussion forum isn't there.

Note: all discussion forums under all articles on this news site are missing.
The first error message shown in console is:
Exception { name: "NS_ERROR_STORAGE_CONSTRAINT", message: "", result: 2153971715, filename: "https://www.novinky.cz/EeB5RqHI09SBt1A3Pdk803MBRI0HVXnqwg4UMe/2leOoKzb/c_static_QK_C/aAgg/szn.discussion.embed.es.js", lineNumber: 1, columnNumber: 0, data: null, stack: "n/i<@https://www.novinky.cz/EeB5RqHI09SBt1A3Pdk803MBRI0HVXnqwg4UMe/2leOoKzb/c_static_QK_C/aAgg/szn.discussion.embed.es.js:1:477\nn@https://www.novinky.cz/EeB5RqHI09SBt1A3Pdk803MBRI0HVXnqwg4UMe/2leOoKzb/c_static_QK_C/aAgg/szn.discussion.embed.es.js:1:530\ne.create@https://www.novinky.cz/EeB5RqHI09SBt1A3Pdk803MBRI0HVXnqwg4UMe/2leOoKzb/c_static_QK_C/aAgg/szn.discussion.embed.es.js:1:25262\nloadDiscussion/<@https://www.novinky.cz/EeG28ifBqlhEx0VHBDeizClJi6BSGlPzUh0U6o5bJORIxURxxbl29yRq3/49M5m2f9j3RIKv2zd9gUuhIyB3uO5nv4rixsdZzb?version=0.14.250:7:231345\n" }
49M5m2f9j3RIKv2zd9gUuhIyB3uO5nv4rixsdZzb:7:231451



Expected results:

The discussion forum should appear.
Bug: fetch useless favicon with link shortcut icon customization there
Status: NEW
Priority: --
Created: 2021-07-15 03:52:12+00:00
Resolved: 2021-07-20 08:47:18+00:00

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

Steps to reproduce:

1. create 2 web pages (linked each other) with customized favicon tag,  <link rel="shortcut icon" href="favicon.production.ico">
2. serve these pages
3. open the page 1 and click link to page 2
4. open developer tools -> network tab
5. press browser native backward button
6. check network tab to find two network access:
* favicon.ico
* favicon.production.ico




Actual results:

Firefox tries to make two fetches:
1. favicon.ico
2. favicon.production.ico

The first one is useless and makes a 404 request to the web server.


Expected results:

Firefox tries to make one fetch:
1. favicon.production.ico
Bug: [XFA] Static fields are not limited to the width or height of the field
Status: NEW
Priority: P3
Created: 2021-07-15 10:18:12+00:00
Resolved: 2022-03-09 23:39:54+00:00

**Note**
* When the user loads a specific PDF, scrolls to page 2, and inputs text into the static fields that are limited to width and height, he will notice that the limit is not respected.

**Affected versions**
* Nightly v92.0a1

**Affected platforms**
* all

**Steps to reproduce**
1. Launch browser.
2. Flip the pdfjs.enableXfa to true.
3. Load the attached PDF file.
4. Scroll to page 2.
5. Input text into the fields to test the limit.

**Expected result**
* Text input is limited to the width and height of the fields.

**Actual result**
* Text input is NOT limited to the width and height of the fields.

**Regression range**
* This is not a regression.
Bug: [XFA] Static field with unlimited input and automatic font decrease does not allow input
Status: NEW
Priority: P2
Created: 2021-07-15 10:26:47+00:00
Resolved: 2022-03-09 23:43:36+00:00

**Note**
* When the user loads a specific PDF, scrolls to page 3, and inputs text into the right static field, he will notice that the field does not allow input at all.

**Affected versions**
* Nightly v92.0a1

**Affected platforms**
* all

**Steps to reproduce**
1. Launch browser.
2. Flip the pdfjs.enableXfa to true.
3. Load the attached PDF file.
4. Scroll to page 3.
5. Input text into the right-side text field.

**Expected result**
* The field allows input.

**Actual result**
* The field does not allow input.

**Regression range**
* This is not a regression.
Bug: [XFA] Dynamic PDF displays page content incorrectly
Status: NEW
Priority: P3
Created: 2021-07-15 10:43:03+00:00
Resolved: 2022-02-11 17:01:28+00:00

**Note**
* When the user loads a specific PDF and compares it to how it displays in Adobe Reader, he will notice that the page content is incorrectly displayed. The content from the second page is displayed at the end of the first page's content and the rest of the pages are not displayed.

**Affected versions**
* Nightly v92.0a1

**Affected platforms**
* all

**Steps to reproduce**
1. Launch browser.
2. Flip the pdfjs.enableXfa to true.
3. Load the attached PDF file.
4. Compare to how it displays in Adobe Reader.

**Expected result**
* The content displays correctly.

**Actual result**
* The content displays incorrectly; The content from the second page is displayed at the end of the first page's content and the rest of the pages are not displayed.

**Regression range**
* This is not a regression.