av9ash/GitBugs huggingface dataset:
Bug: Port |Bug 752376 - Avoid calling scrollbox.ensureElementIsVisible() if the tab strip doesn't overflow to prevent layout flushes| to SeaMonkey
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-01-02 17:14:21+00:00
Resolved: 2020-11-01 20:04:54+00:00

Port the following bug:
* Bug 752376 - Avoid calling scrollbox.ensureElementIsVisible() if the tab strip doesn't overflow to prevent layout flushes
Bug: SeaMonkey (Mac) update version 2.49.5 made it impossible to edit old webpages!
Status: UNCONFIRMED
Priority: --
Created: 2020-01-04 02:32:49+00:00
Resolved: 2020-01-05 06:00:56+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.4 Safari/605.1.15

Steps to reproduce:

I was editing old webpages, just changing the wording in some text.. 


Actual results:

My page backgrounds disappeared and the placement of graphics was way off. I wasted 2 hours, doing everything carefully and testing my results step by step, but it was impossible to get things right. 

I had to go back to SeaMonkey version 2.49.4 in order to keep my page backgrounds and the placement of graphics. I wasted 2 hours today with version x.5 until I finally restored version x.4, and then everything went smoothly. 


Expected results:

I should have been able to edit the text and then upload the edited webpages to my website. But even pages that looked almost OK in SeaMonkey did not look OK in Safari and Chrome. Once I restored the older x.4 version, everything worked as it always has. I love SeaMonkey because of how simple it usually is!

(But I wish I could open composer and drag files into it instead of having to browse for them.)
Bug: Release Notes: Drop "Features" link to Wiki
Status: NEW
Priority: P5
Created: 2020-01-04 12:52:00+00:00
Resolved: 2020-03-08 07:36:18+00:00

AFAIK there has never been useful contents on the SeaMonkey [Features Pages](https://wiki.mozilla.org/SeaMonkey/Features/)  for ages:

At least those for | [2.49.4](https://wiki.mozilla.org/SeaMonkey/Features/2.49.4) | [2.49.3](https://wiki.mozilla.org/SeaMonkey/Features/2.49.3) | [2.49.2](https://wiki.mozilla.org/SeaMonkey/Features/2.49.2) | [2.49.1](https://wiki.mozilla.org/SeaMonkey/Features/2.49.1) | [2.48](https://wiki.mozilla.org/SeaMonkey/Features/2.48)  | [2.46](https://wiki.mozilla.org/SeaMonkey/Features/2.46) |  [2.48](https://wiki.mozilla.org/SeaMonkey/Features/2.48) | [2.40](https://wiki.mozilla.org/SeaMonkey/Features/2.40) | [2.33.1](https://wiki.mozilla.org/SeaMonkey/Features/2.33.1)  |are empty or only contain a lonely hypelink.

For [2.39](https://wiki.mozilla.org/SeaMonkey/Features/2.39) | [2.35](https://wiki.mozilla.org/SeaMonkey/Features/2.35) | there was some minimum contents.

If we don't have contents for the WIKI that item below "Other Resources and Links" should be dropped.
Bug: Port |Bug 822068 - The content loses focus after calling gBrowser.moveTabBackward/moveTabForward| to SeaMonkey
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-01-04 17:10:43+00:00
Resolved: 2020-11-01 20:06:26+00:00

Port the following to SeaMonkey:
* Bug 822068 - The content loses focus after calling gBrowser.moveTabBackward/moveTabForward
Bug: rss folder management buggy
Status: UNCONFIRMED
Priority: --
Created: 2020-01-06 12:04:04+00:00
Resolved: 2020-01-09 07:21:32+00:00

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

Steps to reproduce:

I subscribed to RSS feeds and managed them in folders.


Actual results:

The folder management is very confusing. Sometimes one feed gets splitted into a folder and messages part which will not end up in the same folder.
Sometimes the feed is recieved in the main folder while displayed in the subfolder. You also will need a restart in order to get things displayed properly in the feed subscriptions.

I attached an example (where feed names where shortened due to privacy reasons). You see that the matrixorg feed appears twice in the subscription list alhough it was subscribed once. You also don't see it twice in the main window, but you might have odd results like recieving new messages in the wrong folder.

This might be related to a 15 year old bug, which I also experienced:
https://bugzilla.mozilla.org/show_bug.cgi?id=296264


Expected results:

There sould just be one object that can be moved easily between the folders.
Bug: Attachments won't upload after latest update
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-01-07 22:16:19+00:00
Resolved: 2020-01-08 06:58:36+00:00

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

Steps to reproduce:

In trying to upload an attachment in my mail carrier (Zimbra) the attachment will not send.  Get "Client error has occurred"


Actual results:

Attachment didn't send


Expected results:

Before the latest update, everything worked fine.  Email and attachments sent.
Bug: Install upgrade attempt result in endless reboot requirement and no functioning browser
Status: UNCONFIRMED
Priority: --
Created: 2020-01-16 03:06:08+00:00
Resolved: 2020-01-16 03:08:29+00:00

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

Steps to reproduce:

Ran seamonkey-2.57a1pre.en-US.win64.installer.exe for build 20200114043003.
Forgot to close all running Seamonkey windows first.


Actual results:

The installer required a system reboot to complete the install.
I rebooted the computer.
On reboot, the Seamonkey icon had a different graphic and, on clicking on it, a messagebox popped up saying I needed to reboot to complete the installation.
The same messagebox popped up on my running the installer program, above, again.
Rebooted the system again.
Same situation.
Rebooted the system again.
Same situation.
Deleted all files and directories from C:\Users\...\AppData\Local\Seamonkey, where the Seamonkey application is.
Ran the installer again.
The installer went farther this time and didn't request a reboot, but said, "You don't have sufficient disk space to install to this location."  (There is 245GB of free space.)
Looked in AppData\Local again;  the Seamonkey directory, which I hadn't deleted, was now gone.
Ran the installer again.
Seamonkey installed correctly and works fine.

If it is true that the installer required a reboot because the program was running, that's insane.
If it is true that the installer required a reboot because the program was running, why didn't it give the user a chance to fix the situation before requiring a reboot?
If it is true that the installer required a reboot because the program was running, why would it continue to require a reboot when the program wasn't running, no matter whether or not the reboot finished whatever was to be finished?

The disk space issue seems to be the same as:
https://bugzilla.mozilla.org/show_bug.cgi?id=1215786

I found other bugs, 12, 18, 20 year old, for the installer component that mention the word, "reboot."  A few are:
https://bugzilla.mozilla.org/show_bug.cgi?id=360897
https://bugzilla.mozilla.org/show_bug.cgi?id=138840
https://bugzilla.mozilla.org/show_bug.cgi?id=110882
https://bugzilla.mozilla.org/show_bug.cgi?id=119530
https://bugzilla.mozilla.org/show_bug.cgi?id=43792
I have another program, I forget which, which won't run because it thinks my Windows version is too old; turns out it's because I have disabled some Windows Service, I forget which.
Perhaps the installer also thinks my Windows version is old.
I am running Windows 10, 1803.


Expected results:

Install.
Bug: dragleave event returns bad target, event.relatedTarget is not set
Status: RESOLVED
Priority: P2
Resolution: INVALID
Created: 2020-01-17 11:32:20+00:00
Resolved: 2020-06-14 12:11:32+00:00

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

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171024165158

Steps to reproduce:

1. download the attachment and open it in Firefox.
2. drag something into the page and then drag out.


Actual results:

When dragleave fires, the event.target is set to document (if e10s activated) or XULDocument (if e10s not activated; and accessing event.target throws an error in this case).


Expected results:

The event.target should be the .dropmask element. (in other browsers)
Bug: Bookmark import multiplies blanks in Bookmark Text
Status: RESOLVED
Priority: P4
Resolution: INVALID
Created: 2020-01-17 16:34:03+00:00
Resolved: 2020-01-24 18:21:38+00:00

Steps how to reproduce  with installation of unofficial (by wg9s) De SeaMonkey 2.53.2 (NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build 20191230130008  {Milestone=60.3.2 | SourceStamp=f3720549528fd4e297a4b9f285acd2fe1d0a6938} (Default Classic Theme) on German WIN7 64bit:

0. Create some bookmarks and bookmark folders with a single Blank in Names between words
1. Export Bookmarks via Menu ˋBookmarks → Edit Bookmarks → Tools → Export to HTML
   → Savebookmarks fileˊ
2. Switch to newly created User Profile, import Bookmarks vie Manu ˋBookmarks → Edit Bookmarks → Tools → Import HTML
3. Check Bookmarks in sidebar or Bookmarks Editor, you fill find names damaged by added blanks in strings. 😥
4. Open exported "bookmarks.html",  check the same strings they are ok ☺

Example: See Heading "SeaMonkey DE" in attached Screenshot

**Additional Information**:
a) Curently I can't tell whether this is SM Version related
Bug: Seamonkey 2.53.1 grinding to a halt
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2020-01-21 11:33:55+00:00
Resolved: 2021-02-07 13:49:47+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.1 Lightning/5.8.1

Steps to reproduce:

Mac OS X 10.14.3.  2.6 GHz Intel Core i7. 16 GN Ram 2400 MHz DDR4. MacBook Pro, 15inch 2018.  
Just been using Seamonkey as normal.
The rainbow cursor keeps coming up at just about every action, as the system grinds down to killing then restarting. This really should not happen. As I am doing this, the rainbow cursor keeps making the typing stop for several seconds, and every action I have to wait several seconds for the rainbow cursor to stop spinning. 

I had two websites up, on two tabs

https://www.bbc.co.uk/sport/football/51184842
https://www.lse.co.uk/members/watchlists/




Actual results:

Seamonkey is grinding to a halt. Cannot cope. It can't evenm cop with this website. 


Expected results:

Normal easy browsing that doesnt use up hardly any CPU.
Bug: Release Notes: Dead Link to "Thunderbird 60.3 release notes"
Status: RESOLVED
Priority: P5
Resolution: FIXED
Created: 2020-01-21 16:31:21+00:00
Resolved: 2020-01-22 12:56:33+00:00

Link behind text "Thunderbird 60.3 release notes" leads to Error Message "[There’s nothing here!](https://www.thunderbird.net/en-US/thunderbird/60.3/releasenotes/)"
Bug: Keeps Pausing during normal use.
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-01-23 12:06:53+00:00
Resolved: 2020-01-25 10:56:34+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.1 Lightning/5.8.1

Steps to reproduce:

Only Two websites, this one and https://www.lse.co.uk/members/watchlists/

Just about each and every action, like resize the window and inch, search some criteria, write inside text box like this one I'm writing now, go to the file menu, switch windows fromone seamonkeyt browser to another, type a new sentence, almost all of these and everytime something is done, there is a delay of 2 to 3 seconds whilst Seamonkley thinks about something, and gives me the rotating rainbow pie chart cursor.



Actual results:

This is making this new seamonkey unusable.

Is it checking the internet every 10 seconds ?

The attached movie shows, how the program keeps halting, however screen shoton the mac doesn't record the rainbow cursor for some reason. but you can clearly see when it pauses.


Expected results:

I have uploaded a screen shot movie here, link lasts 5 days or so.

https://we.tl/t-iBxAge67jp

We want to see normal fluid brousing and using without having to wait any time at all for anything.

So i'd thought i would type away at some of this to show you exactly what I mean.
Well there you go, a raindow cursor comes up just between these two sentences. I wonder if it will happen again, it usually only takes about 10 to 20 seconds. Well there you go. just to show you how annoying it is for the program to keep stopping all the time whilst it keeps catching up with itself. Hopeless, it makes seamonkey become unuseable.
Bug: Sending digital signed E-Mail does not work in Version 2.53.1 Beta 1
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-01-25 14:02:23+00:00
Resolved: 2021-02-07 13:56:30+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.1 Lightning/5.8.1

Steps to reproduce:

I did use my existing profile from the latest stable Seamonkey version for the Version 2.53.1 Beta 1
I tried to send a mail (my standard setting is to ad a digital signature).

After it did not work I checked, if my certificate is found bei Seamonkey and still valid (see Attachment).
I still can send e-Mails without signing them.



Actual results:

My German Version said (translated by Google Translate):
"Sending the message failed.
You indicated that this message should be digitally signed, but the application could not find the signature certificate that you specified in your Mail / News account settings, or the certificate has expired."



Expected results:

The e-Mail should have been sent.
Bug: Poorly rendered website
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-01-26 12:21:53+00:00
Resolved: 2020-05-30 15:43:44+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.1 Lightning/5.8.1

Steps to reproduce:

Went to a website I go to several times per day via my Seamonkey bookmarks.


Actual results:

Got to the page fine, as usual. Most of the page is readable just fine, and I get the information I want/need, but there are good chunks of the page that just aren't correct and look like it isn't working correctly at all.


Expected results:

Just a clean, uncluttered page.
Bug: Element.scrollIntoView does not follow spec handling "null", "{}" input arguments
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2020-01-26 12:46:40+00:00
Resolved: 2020-12-23 20:43:29+00:00

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

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

Steps to reproduce:

See spec test result here: 

http://wpt.fyi/cssom-view/scrollIntoView-empty-args.html


Actual results:

The scroll goes to "nearest" or "end". I am not sure but either way it is incorrect.


Expected results:

In particular the tests fail when input is either "null" or {}. In this case according to the spec [1] the method should use default values in ScrollIntoViewOptions which is "center".



dictionary ScrollIntoViewOptions : ScrollOptions {
  ScrollLogicalPosition block = "center";
  ScrollLogicalPosition inline = "center";
};


[1] https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions
Bug: Don't always update lastRelatedTab information when browser.tabs.insertAllTabsAfterCurrent is true
Status: ASSIGNED
Priority: --
Created: 2020-01-30 16:25:48+00:00
Resolved: 2020-02-04 12:47:28+00:00

Bug 1353428 add a pref for opening all new tabs after the current tab. lastRelatedTab information should not be updated when the current tab is not related.
Bug: download manager backend not initilaized if SeaMonkey is not started as normal browser (non private navigator) first
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-02-02 14:24:29+00:00
Resolved: 2020-11-01 20:15:06+00:00

The sessionstore-windows-restored notification is not send if you start SeaMonkey with the private flag or with another component like mail/news. This means that the code in this._onBrowserStartup(subject) in nsSuiteGlue.js is not run initially. This wasn't much of a problem previously but now the jsdownloads backend is initialised here among other things. Currently this results in the download names not shown if you open it. Also the progress dialog is not shown. The taskbar is also not intialised. 

Workaround: As soon as you open a normal browser window the notification is send and the init code executed.

Not sure what the best solution is. Firefox sends the notification if only a private window is opened but our seession store is more or less different and outdated. Send it with a null window like in Fx also results in the notfication not shown (see Bug 573384) and if we have only a address book or mailnews window the startup code will like fail to show a notification too.

So probably best do move some components out of _onBrowserStartup and into a delayed startup like in Firefox after final-ui-startup is received.

I am not sure if we can fix it for 2.53.1 but if not the workaround should be put into the release notes.
Bug: Disable startup cache in SeaMonkey 2.53 and 2.57 build config.
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-02-02 14:33:20+00:00
Resolved: 2021-04-30 12:32:44+00:00

The startup cache causes problems with enabling and disabling extensions and themes in 2.53.1 and up. Initial findings suggest that any performance gain here is neglectable so it should be disabled by default. 
This can be done by providing --disable-startupcache as an option in the mozconfig file but we probably want it by default so that distributions don't need to do it too.

See:
Bug 1444957
Bug 1484393
http://forums.mozillazine.org/viewtopic.php?f=6&t=3058711&p=14856248#p14856248
Bug: "New bookmark folder" dialog crippled, input fields missing
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-02-04 07:28:01+00:00
Resolved: 2020-02-05 00:54:00+00:00

Steps how to reproduce  with installation of unofficial (by wg9s) De SeaMonkey 2.53.2 beta 1 pre Mozilla/5.0  (NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build 20200131130001  (Default Classic Theme, newly created User Profile) on German WIN7 64bit:

1) Launch Browser
2) Open Bookmarks Panel in Sidebar
3) on a bookmark entry:  ˋRightclick → New Folderˊ
   » Expected: Dialog opens with input fields for folder name and comment

    Actual: Input fields are missing 😥

**Additional Information**

**a1)** Already reproducible with unzipped installer of unofficial (by wg9s) De SeaMonkey 2.53.2 beta 1 pre Mozilla/5.0  (NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build 20200131130001  (Default Classic Theme, newly created User Profile) on German WIN7 64bit
**a2)** Was still ok with unzipped unofficial (by wg9s) De SeaMonkey 2.53.1 (NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build 20191229130005  (Default Classic Theme) on German WIN7 64bit
**a)** Appeared with 2.53.2?    
**b)** Also affected: ˋbookmarks → edit bookmarksˊ
Bug: Fix styling for prefwindows and dialog headers
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-02-08 22:30:42+00:00
Resolved: 2020-02-08 23:46:31+00:00

The following bugs fixed most of the issues:
* Bug 1427864 - SM: Restore the dialogheader binding and its styling after the removal in bug 1419600
* Bug 1424602 - SM: Restore the Preferences bindings/styles after their removal in bug 1379338
but:
* setting the font to message-box was missed for prefwindows
* dialog heading css was not copied into the linux version of communicator.css
Bug: Cutting and Pasting folders within the bookmark manager causes the cut folder to disappear instead of being moved
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2020-02-09 22:13:49+00:00
Resolved: 2020-02-10 10:08:27+00:00

CTRL-B
Click the bookmarks menu
Create a folder TEST1
Create a folder TEST2
Create a new test bookmark in folder TEST2
Create a 2nd test bookmark in folder TEST2
Cut folder TEST2 and try to paste it into TEST1.  Folder TEST2 disappears.

NOTE: dragging and dropping folders works as expected only cutting and pasting folders appears to not function correctly.
Bug: Port |Bug 670033 - Persist deferred session across a browser restart| and |Bug 1001167 - Don't let invalid sessionstore.js files break sessionstore| to SeaMonkey
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-02-17 23:58:27+00:00
Resolved: 2020-11-01 20:30:23+00:00

Port the following to SeaMonkey:
* Bug 670033 - Persist deferred session across a browser restart
* Bug 1001167 - Don't let invalid sessionstore.js files break sessionstore
Bug: Severe memory usage
Status: RESOLVED
Priority: --
Resolution: WORKSFORME
Created: 2020-02-19 13:35:38+00:00
Resolved: 2022-05-28 21:19:33+00:00

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.1 Lightning/5.8.1

Steps to reproduce:

Just had to browse the internet, on any given day, any given time.

I could have only one site open, or 4 tabs or more and it could end up all the same - getting so slow and waiting for clicks on links to happen or pages to scroll, etc.


Actual results:

It seems eventually Seamonkey starts to eat RAM. I'm not sure when or how, as it seems to happen randomly and no specific websites.

One minute things are going just fine, the next thing I know I'm waiting for the cursor to change when hovering on a link or waiting for the page to scroll, etc. The delays in things to happen usually are a couple seconds but no more than three seconds so far, but the delay in *every* thing I want to do, not just surfing, but doing anything on my computer, has that short delay anytime I want to do anything.

When I open ksysguard to see what might be the problem app, it's Seamonkey using 2+ GB of RAM (of my 12GB).

If I close Seamonkey and open/use Firefox (for instance) and go to the same sites I was just on, with the same number of tabs of the same sites, nothing is going wrong and ksysguard shows it only using around 190MB of RAM, so this was my non-scientific, simpleton test, heh.


Expected results:

Nothing other than just continue to not have the sudden delays for anything to happen on my computer when it suddenly starts to eat RAM.

This is Seamonkey 2.53.1b1
Bug: Canceling/closing bookmark properties dialog undoes previous editing in SeaMonkey
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2020-02-22 13:38:27+00:00
Resolved: 2020-11-01 20:33:25+00:00

The 2.53 patch in Bug 1378089 omitted ports for the following bugs:
Port Bug 1391393 "Canceling Properties of bookmark dialog makes undoing previous editing" to SeaMonkey.
Port Bug 1397387 "No longer able to edit bookmark item after closing New Bookmark or New Bookmark Folder dialog by [x] button" to SeaMonkey. 

2.57 and up have them and are not affected.
Bug: Particular web page causes "script not responding" error
Status: NEW
Priority: --
Created: 2020-02-23 15:36:50+00:00
Resolved: 2022-01-03 18:38:43+00:00

Steps how to reproduce with installation of unofficial (by wg9s) De SeaMonkey 2.53.2 beta 1 pre Mozilla/5.0  (NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build 20200222130008 (Default Classic Theme, newly created User Profile) on German WIN7 64bit:
1) Launch SM 
2) Switch to newly created User Profile ('Extras -> Switch Profile ...')
3) Into URL bar paste https://www.duden.de/rechtschreibung/Recyclinghof  --> [Enter]
   » Expected: Page opens
   » Actual: Error Message: "Script Busy, does not respond", and significant CPU load.     😥

**Additional Info**

a) Not a new problem, already reproducible with 2.49.4 
b) Same Problem with SM 2.49.1 on WIN10