av9ash/GitBugs huggingface dataset:
Bug: Perpetual PDF Spam
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-19 21:28:07+00:00
Resolved: 2024-05-30 17:14:41+00:00

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

Steps to reproduce:

1) Start Firefox by clicking on the desktop icon
2) Press Cmd+N (or Ctrl+N for Windows users) to open a new browser window
3) Search for a PDF file via the search bar in Firefox
4) Open the PDF file by clicking on the link


Actual results:

Upon opening the PDF file, Firefox begins to spam new tabs continuously and the user is unable to exit the browser without force quitting. In addition, the tabs produced have no content at all.

At times, after the user force quits, the background image of the desktop completely disappears along with the time, WIFI icons, etc. located at the top right of the screen. As the user restarts their Firefox browser, they are greeted with a message which says, "Sorry. We're having trouble getting your pages back." and the user has to either restore or start a new session. This shows the main issue regarding the perpetual spam of new tabs upon opening a PDF file in Firefox, but it seems as if the black background and the computer freezing issue only occurs at times and at other times, doesn't. The issue demonstrated also affected the Finder and any other applications of the Macbook since they all froze and I wasn't able to move any applications at all.

Device used: 2012 Macbook Air


Expected results:

Expected Result: Upon opening the PDF file, the file should have been successfully opened without spamming multiple tabs and the user should still have the ability to interact with the computer.
Bug: Ebay appears as search engine but with no icon (one-offs & Search engines)
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-05-19 21:45:47+00:00
Resolved: 2020-06-11 19:36:04+00:00

While running tests we noticed that when we installed beta 67.0b9 and updated firefox to the latest beta 77b7,  the ebay icon dissapeared. The functionality is still there and i can click on it. It just appears empty  on one-offs and also in firefox settings.

This does not happen if we install the latest beta from scratch, it only happened updating the browser.

Tested on Windows10 + Windows7


-Steps to reproduce:

1) download firefox beta  67.0b9
2) Create prefs.js  with:
    user_pref("app.update.auto", false);
    user_pref("browser.search.region", "RU");
    user_pref("browser.search.log", true);

3) put prefs.js in new profile folder
4) launch firefox with the new profile and check search engines and update it.
5) after update, check engines again



-Actual Result:        
              Ebay is visible with a empty icon (in megabar one-offs  and also in firefox search settings)


-Expected Result :     
                It should not show like that




-Notes:

We tested this using windows10 and Windows7 so far, and the issue is visible on both

I also tried to replicate using Firefox Release and Firefox Nightly but i was not able to see the problem on those, I tested these versions and was not able to see the problem:

Nightly:     67.0a1  , 68.0a1   ,77.0a1 
Release:    66, 67, 68, 74, 75
Beta:         75.0b9 , 76.0b9
Bug: Checkbox for 'Notify about new features' for What's New panel hidden for some locales
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-19 23:22:19+00:00
Resolved: 2020-07-02 00:41:06+00:00

1. Have Firefox in German (locale code "de"), French should also work. Reproduced with 78.0a1 20200519094847.
2. In the toolbar, click the button with three horizontal lines on the right.
3. Click the menu item with the gift icon near the bottom.

Actual result: What's New panel option to notify on new content/changes doesn't have it's checkbox shown.

Expected: Checkbox shown like in English.
Bug: Latest Win64 Firefox Nightly isn't loading webpages on Windows 10
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-20 00:18:12+00:00
Resolved: 2020-06-10 14:55:26+00:00

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

Steps to reproduce:

Update Win64 Nightly on Windows 10


Actual results:

Web pages no longer display or load after the update


Expected results:

Web pages should display and load after the update
Bug: On Nightly no sites are loading.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-20 01:19:43+00:00
Resolved: 2020-05-20 11:32:52+00:00

I updated to the most recent nightly on windows and all my active tabs are not loading. Just giving favicon spinners. The only exception was a tab that was a single image and one that was reader mode. Presumably this came from cache?

A Mac user in #nightly:mozilla.org indicated the same behavior. They said that things worked in private windows and safe mode, but I did not try testing these. I've updated to a day old build in order to keep running with this profile.
Bug: Add-on Firefox Multi-Account Containers broken in Nightly 78.0a1 (2020-05-19)
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-20 05:22:05+00:00
Resolved: 2020-05-20 11:32:53+00:00

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

Steps to reproduce:

1. Created new firefox profile for clean environment via about:profile
2. Launched newly created profile and installed Firefox Multi-Account Containers 6.2.5 from the mozilla addon store.
3. Closed the newly created running profile and reopened for addon install to take effect
4. Browse to url www.google.com
--
Build ID: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 ID:20200519160549
Installed Extensions list: Amazon.com 1.1
Bing 1.1
DuckDuckGo 1.0
Firefox Multi-Account Containers 6.2.5
Google 1.0
Nightly Tester Tools 4.0
Twitter 1.0
Wikipedia (en) 1.0


Actual results:

Page takes a long time to load/appear


Expected results:

Page would have loaded with minimal delay with Multi-Account Containers disabled
Bug: With Disconnect addon enabled, websites are unable to load
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-20 08:39:37+00:00
Resolved: 2020-05-20 17:30:39+00:00

This is with latest released Nightly. I managed to figure out that the broken state of my Firefox (no website able to load) was caused by Disconnect addon presence.

Problem is that this addon is installed for a very very long time, and its last update is from July 2019, so it's unlikely anything changed here, which makes me think to a regression in Firefox and some addon APIs used by that addon.
Bug: window.open() triggers GET request twice after 74.0.0 and newer
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-05-20 09:50:48+00:00
Resolved: 2020-06-09 20:35:43+00:00

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

Steps to reproduce:

Opening window.open(<GET_REQUEST>, "pop-up",  "toolbar=no, location=no, directories=no, menubar=no") in version 74 and higher triggers GET request twice


Actual results:

When I try to open a pop-up window using window.open(<GET_REQUEST>, "pop-up",  "toolbar=no, location=no, directories=no, menubar=no"), the request was actually triggered twice (I'm using Fiddler 4 for tracking request traffic). The strangest thing is the fact that it happens to me only in version 74 and higher! I have tested the same code in 4 random versions < 74 (73.0.1, 72, 71, 66.0.5) and never noticed this behaviour.

I went through the changelog of 74.0 but did not find something suspicious or related to this.


Expected results:

Opening window.open(<GET_REQUEST>, "pop-up",  "toolbar=no, location=no, directories=no, menubar=no") should triggers request only once.
Bug: [Ubuntu 20] Window controls are barely visible on light theme
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2020-05-20 10:18:29+00:00
Resolved: 2021-12-07 02:51:07+00:00

**Affected versions**
- Firefox 76.0.1
- Firefox 77.0b8
- Firefox 78.0a1

**Affected platforms**
- Ubuntu 20 (x64)

**Steps to reproduce**
1. Launch Firefox
2. Access customize from the menu
3. Unselect Title Bar (it is on by default)
4. Activate light theme

**Expected result**
- Window controls (minimize, maximize) are visible

**Actual result**
- Window controls (minimize, maximize) are barely visible

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

**Additional notes**
- The issue can be seen on the attachment.
Bug: [Ubuntu 20] Menu scrollbars are not visible while dark theme is applied
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2020-05-20 11:43:41+00:00
Resolved: 2023-01-25 17:12:53+00:00

**Affected versions**
- Firefox 76.0.1
- Firefox 77.0b8
- Firefox 78.0a1

**Affected platforms**
- Ubuntu 20 (x64)

**Steps to reproduce**
1. Launch Firefox
2. Visit ~10-15 sites to have in history
3. Apply the dark theme
4. Click on "View History, saved bookmarks and more" --> History for example

**Expected result**
- The scrollbar is visible

**Actual result**
- The scrollbar is not visible

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

**Additional notes**
- The issue can be see in the attachment
- Seems to be happening if Ubuntu theme is set to standard
- Scroll is visible only if it is hovered over
Bug: Initial page load keeps the location bar empty
Status: RESOLVED
Priority: P5
Resolution: DUPLICATE
Created: 2020-05-20 11:45:21+00:00
Resolved: 2020-11-04 23:05:56+00:00

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

Steps to reproduce:

1. I click on a link for a page that only loads over a VPN, but I forgot to connect to the VPN.

2. I realize the page isn't loading and connect to the VPN.


Actual results:

Firefox takes a long time to time out the initial connection.

I try to speed this up by canceling the page load by clicking the X icon in the location bar (so it'll turn into a reload icon), the location bar becomes empty! 

If I don't cancel but wait a long time, Firefox puts the URL of the failed load in the URL bar, and _now_ I can hit reload.


Expected results:

The URL should appear in the location bar immediately, so I can cancel the load and hit reload whenever I want, without waiting for the initial load attempt to time out.
Bug: Firefox nightly update 5/20/2020 incompatible with addon: I Don't Care About Cookies
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2020-05-20 12:24:37+00:00
Resolved: 2020-05-20 12:53:01+00:00

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

Steps to reproduce:

https://www.i-dont-care-about-cookies.eu/  Install addon on 
78.0a1 (2020-05-19) (64-bit)



Actual results:

Web pages will not load from any website.  Pages attempt to load indefinitely.


Expected results:

Web pages load normally. This worked prior to the most recent nightly update.
Bug: [Intermittent] Firefox menu flickers when opened after restart or with a new profile
Status: RESOLVED
Priority: P3
Resolution: WORKSFORME
Created: 2020-05-20 14:00:31+00:00
Resolved: 2022-12-07 19:36:46+00:00

*Affected versions*
* 78.0a1 (20200520033931)
* 77.0b8 (20200519220135)
* 76.0.1 (20200507114007)


*Affected platforms*
* macOS 10.12
* macOS 10.15

*Steps to reproduce*
1. Open Firefox with a new profile and click on the hamburger menu.



*Expected result*
* No visual glitches are presented.


*Actual result*
* Firefox menu flickers on opening. If not restart Firefox and try again.

*Regression range*
* Will search for one ASAP.

*Notes*
* Attached a screen recording.
* The issue may be intermittent.
Bug: Persistent Private mode is not kept after Restart to update intervention is selected.
Status: NEW
Priority: P3
Created: 2020-05-20 15:03:13+00:00
Resolved: 2022-12-19 16:55:52+00:00

**Description**
When in persistent private mode, if i use the update firefox intervention, it restarts to normal mode and not private.

**Tested on**

Windows10 64bit, MacOS 10.14, ubuntu 18.04 64bit  (all affected)
Using FF nightly 78.0a1, FF release 76, FF beta 77.0b6  (all affected)



**Steps to reproduce**

1) Download an older version of firefox, example a version from last week
2) Create a new profile and set "use the selected profile without asking at startup" on profile manager.
3) Launch firefox with -private from command prompt and select the new profile
4) open a youtube video on a a tab, and wait some minutes for firefox to download the update.
5) type in megabar "update firefox"  and click on "restart to update"
6) firefox is restarted, i see in history there is no youtube.
7) Now go to cnn.com  and then close firefox.
8) Launch firefox again with -private
9) check /view history

**Actual result:**
  You are on persistent private mode and you see cnn.com in history

**Expected result**
   Cnn.com should not be in history, might be because after restart on step#5, it restarted to non-private mode.
Bug: Opening PDF in system default always opens in new tab
Status: VERIFIED
Priority: --
Resolution: FIXED
Created: 2020-05-20 15:36:26+00:00
Resolved: 2020-11-10 18:04:07+00:00

When trying to open a PDF with the system default app, it is instead opening in Nightly. This appears to be because we now try to prefer opening PDFs in Nightly from the Downloads Panel (bug 1191591) but that code is also running when the file is being downloaded, not just from the panel.

STR
1. Go to https://www.irs.gov/pub/irs-pdf/f1040.pdf.
2. Click "Open With a Different Viewer".
3. Select Open with and the default option.

Expected results: The PDF is opened in your system PDF viewer.
Actual results: The PDF opens again in a new tab in Nightly.
Bug: [Protections Dashboard 1.5] Monitor card cache has stopped working
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-05-20 16:18:26+00:00
Resolved: 2020-05-26 19:13:04+00:00

The Monitor card now fully updates with each refresh, we should look into why this changed, and either fix the cache or remove related code.
Bug: Sync logs state that addon, address, form, prefs, history sync disabled via preference, but is not disabled
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-05-20 16:44:20+00:00
Resolved: 2020-07-02 00:27:26+00:00

Created a fresh profile of Firefox last night and was surprised to not see my add-ons populate as usually occurs in new profiles.

Looked in my sync logs and saw lines like:

```
1589992786861	Sync.Doctor	INFO	Skipping check of prefs - disabled via preferences
1589992786861	Sync.Doctor	INFO	Skipping validation of passwords: too recent since last validation attempt
1589992786861	Sync.Doctor	INFO	Skipping check of tabs - disabled via preferences
1589992786861	Sync.Doctor	INFO	Skipping validation of bookmarks: too recent since last validation attempt
1589992786861	Sync.Doctor	INFO	Skipping check of addons - disabled via preferences
1589992786861	Sync.Doctor	INFO	Skipping check of addresses - disabled via preferences
1589992786861	Sync.Doctor	INFO	Skipping check of forms - disabled via preferences
1589992786861	Sync.Doctor	INFO	Skipping check of history - disabled via preferences
```

which is not true. 

Why is this?
Bug: PDF file not rendered correctly in Firefox
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-05-20 16:51:30+00:00
Resolved: 2021-08-13 16:51:32+00:00

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

Steps to reproduce:

Open the attached PDF file using Firefox.


Actual results:

The Pie chart at the top of the PDF file is missing one of its pieces.


Expected results:

The PDF file should render correctly as it does in Adobe Acrobat or Chrome.
Bug: Unintuitive behaviour on right-click context menu
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-20 18:36:03+00:00
Resolved: 2020-05-21 15:14:28+00:00

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

Steps to reproduce:

I am running Firefox 69 on Fedora 31 under Wayland.

Open a new Firefox window (in safe mode or in the course of regular operation). Navigate to any given website (such as example.com). Right-click near the bottom of the window (maybe 100px or so up from the bottom border). A context menu shall appear, just above the mouse position, with options including "Save Page As...". Move the mouse so that it is horizontally aligned with the context menu but is vertically below it. 


Actual results:

With the mouse below the context menu, the options in the menu will highlight as though the mouse is several pixels up. Clicking does not perform the highlighted action, but the visual feedback would seem to indicate that Firefox thinks the mouse is over the context area, or perhaps that Firefox thinks the context area spawned below the mouse rather than above. See the attached screenshot for a better depiction. Notice that ,in the screenshot, the "Save Page to Pocket" option in the context menu is highlighted even though the mouse is clearly below the context menu, not within its bounds.


Expected results:

The context menu should remain visible but no options should appear highlighted.
Bug: High CPU load on https://www.tvnow.de due to Video DownloadHelper
Status: NEW
Priority: P5
Created: 2020-05-20 18:45:13+00:00
Resolved: 2023-01-27 13:49:26+00:00

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0 ID:20200520033931

Watching videos on that given platform the Video DownloadHelper (currently version 7.3.9 installed) causes constant hangs / freezes of the currently played video.

Here a recorded gecko profile: https://perfht.ml/3bNLK6t

As it looks like a lot of async messages are getting sent back and forth between the webextension and the parent process. But there are also a couple of long running cycle collector calls.

Could someone please have a look what might cause that?
Bug: Report server_error on HTTP 5XX when polling for changes
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2020-05-20 19:25:08+00:00
Resolved: 2020-05-22 09:52:35+00:00

A `server_error` is reported during sync if the server returns a 5XX.

But when polling for changes, we report a `content_error` because the CDN transform 5XX errors in HTML and serve them with content type text/html instead of application/json. 

We should check for the HTTP status first
Bug: Can't open a PDF in the external PDF viewer anymore
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-05-20 21:28:39+00:00
Resolved: 2020-05-20 21:59:29+00:00

Trying to open a PDF in an external application doesn't work, at least on Linux.

STR:
1. Go to https://www.cesu.urssaf.fr/info/files/pdf/modele_solde_tout_compte.pdf
2. Try to download the PDF, either with the "open with different viewer" notification, or the "download" button. This also happens when a PDF is offered for download directly because of a `Content-Disposition: attachment` header.
3. Select the "Document Viewer" (evince)

=> This opens inside Firefox instead of opening in the external app.

I think this is quite new.
Bug: Integrate DuckDuckGo bangs with the Firefox address bar
Status: RESOLVED
Priority: --
Resolution: WONTFIX
Created: 2020-05-20 21:52:55+00:00
Resolved: 2020-05-25 13:29:40+00:00

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

Steps to reproduce:

1. Set DuckDuckGo as your default search engine.
2. Type a search query with a bang, like !a or !w.


Actual results:

The address bar says that it will search DuckDuckGo.


Expected results:

The address bar should state that it is searching the site's engine.

As a result, Firefox should look up the names of DuckDuckGo bangs whenever they are typed into the address bar with DuckDuckGo as the default search engine, and the address bar would have the site name.
Bug: `trackRemainingChanges` is a method on the engine, not the store
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2020-05-20 22:14:00+00:00
Resolved: 2020-05-22 20:17:00+00:00

Oops! This came up in an error log in bug 1639625—the engine calls `trackRemainingChanges` on itself after a sync, not on the store! We also need test coverage for this in tabs and prefs.
Bug: Intermittent browser/components/downloads/test/browser/browser_pdfjs_preview.js | leaked 1 window(s) until shutdown [url = file:///C:/Users/task_1590011575/AppData/Local/Temp/testsavedir/downloaded.pdf]
Status: RESOLVED
Priority: P5
Resolution: INCOMPLETE
Created: 2020-05-20 23:23:50+00:00
Resolved: 2020-06-23 17:05:11+00:00

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

---

>[task 2020-05-20T22:09:56.284Z] 22:09:56     INFO - GECKO(5540) | [Parent 5864, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file /builds/worker/checkouts/gecko/netwerk/base/nsNetUtil.cpp, line 2295
[task 2020-05-20T22:09:56.284Z] 22:09:56     INFO - GECKO(5540) | [Parent 5864, Main Thread] WARNING: 'NS_FAILED(rv)', file /builds/worker/checkouts/gecko/caps/ContentPrincipal.cpp, line 398
[task 2020-05-20T22:09:56.285Z] 22:09:56     INFO - GECKO(5540) | [Parent 5864, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file /builds/worker/checkouts/gecko/caps/ContentPrincipal.cpp, line 423
[task 2020-05-20T22:09:56.320Z] 22:09:56     INFO - GECKO(5540) | [Parent 5864, Main Thread] WARNING: Extra shutdown CC: 'i < NORMAL_SHUTDOWN_COLLECTIONS', file /builds/worker/checkouts/gecko/xpcom/base/nsCycleCollector.cpp, line 3359
[task 2020-05-20T22:09:56.447Z] 22:09:56     INFO - TEST-INFO | Main app process: exit 0
[task 2020-05-20T22:09:56.447Z] 22:09:56     INFO - TEST-INFO | Confirming we saw 94 DOCSHELL created and 94 destroyed log strings.
[task 2020-05-20T22:09:56.447Z] 22:09:56     INFO - TEST-INFO | Confirming we saw 238 DOMWINDOW created and 238 destroyed log strings.
[task 2020-05-20T22:09:56.448Z] 22:09:56    ERROR - TEST-UNEXPECTED-FAIL | browser/components/downloads/test/browser/browser_pdfjs_preview.js | leaked 1 window(s) until shutdown [url = file:///C:/Users/task_1590011575/AppData/Local/Temp/testsavedir/downloaded.pdf]
[task 2020-05-20T22:09:56.448Z] 22:09:56     INFO - TEST-INFO | browser/components/downloads/test/browser/browser_pdfjs_preview.js | windows(s) leaked: [pid = 2904] [serial = 1]
[task 2020-05-20T22:09:56.448Z] 22:09:56     INFO - TEST-INFO | browser/components/downloads/test/browser/browser_pdfjs_preview.js | This test created 1 hidden window(s)
[task 2020-05-20T22:09:56.448Z] 22:09:56     INFO - TEST-INFO | browser/components/downloads/test/browser/browser_pdfjs_preview.js | This test created 1 hidden docshell(s)

*[task 2020-05-20T22:09:54.367Z] 22:09:54     INFO - *** End BrowserChrome Test Results ****
Bug: Session Restore does not restore page anchor position
Status: NEW
Priority: --
Created: 2020-05-21 06:49:51+00:00
Resolved: 2023-07-17 12:19:54+00:00

## Steps to reproduce

1. Enable session restore.
2. Open a page with an anchor link, e.g. a Bugzilla comment link like https://bugzilla.mozilla.org/show_bug.cgi?id=1639797#c0
3. Restart Firefox.

## Expected results

The restored page should scroll to the anchor position.

## Actual results

The restored page is positioned at the top of the page.

Is this by design? Chrome's session restore doesn't restore the anchor position either. Safari's session restore _does_ restore the anchor position when restoring multiple tabs. When restoring just one tab, it restores the anchor position only about 20% of the time?!

See also home page anchor bug 505394 and "Undo Close Tab" anchor bug 1467832.