Closed Bug 1689877 Opened 4 years ago Closed 4 years ago

Tracking bug for build and release of SeaMonkey 2.53.7 Beta

Categories

(SeaMonkey :: Release Engineering, task)

SeaMonkey 2.53

Tracking

(seamonkey2.53+ fixed)

RESOLVED FIXED
Tracking Status
seamonkey2.53 + fixed

People

(Reporter: iannbugzilla, Unassigned)

References

Details

(Whiteboard: SM2.53.7)

Attachments

(2 files, 1 obsolete file)

This is a tracking bug for Build and Release of the SeaMonkey 2.53.7 Beta

Depends on: 1689878
Depends on: 1691208

Some notes about repackage issues.
(repacked calendar appears in omnijar format instead of zip, chatzilla locale appears as flat dir).

First, considering installers-% :

	@$(MAKE) libs-$*
	@$(MAKE) package-langpack-$*
	@$(MAKE) repackage-zip-$*
	@$(MAKE) repackage-extensions AB_CD=$*

"make repackage-zip-$*" actually makes new prepared package (.tar.bz2 in Linux case). Following "make repackage-extensions" just prepares extensions, but the changes are already not used.

Second, repackage-zip calls l10n-repack.py (the actual code seems to be here ).

Once l10n-repack.py sees a file in the omni format in the source directory, it thinks that everything repacked should be in this format as well. If you manually change omni.ja to be an ordinary zip, the issue gone -- all repacked files appear in the ordinary zip too. (Or it consider the format of omni.ja as something to use for all the things).

A solution could be copy all the repackage-zip stuff into comm branch and change it properly.
For example: after the l10n-repack.py, unzip all newly (badly) created xpi files, then run "repackage-extensions", and only then build package .

(And it seems that repack of the classic theme is not needed (could be add to --ignore as well) ).

It would be fine if somebody more familiar with the code moved "repackage-zip" stuff into the comm branch (dropping extra things etc.). I can do further tests if needed then.

Flags: needinfo?(iann_bugzilla)
Flags: needinfo?(frgrahl)

The issue seems fixed.

I've even tested it on Linux (experiencing cognitive dissonance by an application that does not work in the standard UNIX "C" locale) :)

It so happened that at the same time I solved the problem "chatzilla requires an extra langpack extension". This is a case where it is much easier to fix something than to leave it in its original faulty state...

The first, preliminary patch, fixing a certain blot that might appear in omni.ja (unnecessary "extensions" entries).

The problem is that at the time of bug #1231349, the checking for ignorelist was not add in yet another needed place (original commit is https://gitlab.com/seamonkey-project/seamonkey-2.53-mozilla/-/commit/ec46586365725fbbaa15f465692c8b6c1c720445 ). We can ignore something at the application side, but cannot at the locales side, which makes some quircks.

Probably it can work without this patch (ie. with the noise entries in omni.ja), but I don't wanna check it. :)

Attached patch seamonkey-repacks.patch (obsolete) — Splinter Review

Main patch.

"repackage-zip" stuff was copied from mozilla and renamed to "repackage-suite".

In the beginning, when MOZ_IRC, the chatzilla locale stuff is prepared a bit to be suitable for l10n-repack.py (just copied into right place).

l10n-repack.py runs twice.
First run is for all the things except the extensions/ subdir. This way we preserve extensions to be repacked by the inherited "omnijar" format.
Second run is for extensions/ subdir only.

The stuff of former "repackage-extensions" is inserted right before the MAKE_PACKAGE, so now all the prepared things are placed in the resulting package properly.

Since the extra chatzilla langpack seems going away, probably there is enough extra code to be removed followed it...

Attachment #9202175 - Flags: feedback?(iann_bugzilla)
Attachment #9202176 - Flags: feedback?(iann_bugzilla)

v1.

Handle the case when the locale is not supported by chatzilla (i.e. en-US remains unchanged).

Attachment #9202176 - Attachment is obsolete: true
Attachment #9202176 - Flags: feedback?(iann_bugzilla)
Attachment #9202389 - Flags: feedback?(iann_bugzilla)
Attachment #9202175 - Flags: feedback?(iann_bugzilla)
Flags: needinfo?(iann_bugzilla)
Flags: needinfo?(frgrahl)
Attachment #9202389 - Flags: feedback?(iann_bugzilla)
No longer depends on: 1691208

A broken choice of chatzilla's taskbar icon leads to a constant redrawing of the screen.

Disable ALL the extensions (chatzilla, inspector, lightning) in about:addons, and run SeaMonkey from cmdline with debug:

MOZ_LOG="nsRefreshDriver:5" seamonkey

The debug output stopped after the page is completed, until you move mouse etc., then it stopped again etc.etc It is an expected behaviour.

Then enable chatzilla in about:addons and repeat the MOZ_LOG run.

After the page is completed, the debug output still present infinitely, despite you do nothing.

The problem is suite/extensions/irc/xul/skin/images/taskbar-irc.gif icon, with size 16x10 .
It seems the code require geometry of 16x16 in this area. If you try to use png or jpg icon with another size there, it just not appear. But in the case of gif, the icon with the size of 16x10 (instead of 16x16) still appear, with a side effect of permanent refreshing of the screen (according to the debug output).

Most easy fix is just:

--- comm/suite/extensions/irc/xul/skin/chatzillaOverlay.css	2021-03-01 21:18:24.000000000 +0300
+++ comm/suite/extensions/irc/xul/skin/chatzillaOverlay.css-OK	2021-03-15 03:38:47.473601192 +0300
@@ -3,7 +3,7 @@
  * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
 
 #mini-irc {                                                           
-  list-style-image: url("chrome://chatzilla/skin/images/taskbar-irc.gif");
+  list-style-image: url("chrome://chatzilla/skin/images/chatzilla-16.gif");
 }
 
 #tasksMenuIRC {

Certainly it is strange nowadays that these two icons are still in gif, whereas all the other are already in png.

Regarding Mercadolibre issue:

Any search result page of https://www.mercadolibre.com.ve site uses intersection observer (when see that the browser supports it).

Due to poor coding, instead of the use of one observer for all the 55 "lazy loadable" images, the site uses 55 observers which of them handles all the 55 images. So there is a typical O(n^2) case (55*55).

When something is animated in the SeaMonkey's chrome (ie. busy throbber, or loading indicator, or broken case with taskbar-irc.gif), such an animation is handled by the refresh tick driver in layout/base/nsRefreshDriver.cpp:nsrefreshDriver::Tick() . The "animated" document is chrome://navigator/content/navigator.xul .

While the throbber is animated, nsrefreshDriver::Tick() is called to provide refreshing. But for some reasons the page content appears as sub-document of the chrome document, and during nsrefreshDriver::Tick() call it causes non-empty results of CollectDocument(), which then call whole update intersection observers stuff.

So, when something starts to loading in the page (due to ad scripts and similar), the throbber starts animating (showing busy state). The animation causes nsrefreshDriver::Tick() to be called on each tick (60 times per second), and on each tick there are some 55*55 checks because of active intersection observer(s). The result is mentionable high cpu load (up to 100% on the old hardware).

Following patch fixes the issue:

--- mozilla/layout/base/nsRefreshDriver.cpp.orig        2021-03-10 17:37:48.282475839 +0300
+++ mozilla/layout/base/nsRefreshDriver.cpp     2021-03-23 04:11:30.781288248 +0300
@@ -1923,22 +1923,26 @@ nsRefreshDriver::Tick(int64_t aNowEpoch,
   // Update any popups that may need to be moved or hidden due to their
   // anchor changing.
   nsXULPopupManager* pm = nsXULPopupManager::GetInstance();
   if (pm) {
     pm->UpdatePopupPositions(this);
   }
 #endif

-  AutoTArray<nsCOMPtr<nsIDocument>, 32> documents;
-  CollectDocuments(mPresContext->Document(), &documents);
-  for (uint32_t i = 0; i < documents.Length(); ++i) {
-    nsIDocument* doc = documents[i];
-    doc->UpdateIntersectionObservations();
-    doc->ScheduleIntersectionObserverNotification();
+  // Skip chrome animation case (busy throbber and/or loading indicator)
+  // which is not a reason to trigger any observing.
+  if (!mozilla::dom::IsChromeURI(mPresContext->Document()->GetDocumentURI())) {
+    AutoTArray<nsCOMPtr<nsIDocument>, 32> documents;
+    CollectDocuments(mPresContext->Document(), &documents);
+    for (uint32_t i = 0; i < documents.Length(); ++i) {
+      nsIDocument* doc = documents[i];
+      doc->UpdateIntersectionObservations();
+      doc->ScheduleIntersectionObserverNotification();
+    }
   }

   /*
    * Perform notification to imgIRequests subscribed to listen
    * for refresh events.
    */

   for (auto iter = mStartTable.Iter(); !iter.Done(); iter.Next()) {

The idea is to skip intersection observation stuff when refresh tick is actually called for non-content (ie. chrome).

During discovering the issue, there are at least three additional bugs found, which could be backported -- bug #1402197, bug #1433336 (3 commits), bug #1340684 and bug #1433019 .

After the bug #1433336 applied the proposed patch will look simplier:

--- mozilla/layout/base/nsRefreshDriver.cpp-MB  2021-03-23 04:07:18.364312216 +0300
+++ mozilla/layout/base/nsRefreshDriver.cpp     2021-03-23 04:07:53.958026822 +0300
@@ -1978,17 +1978,21 @@ nsRefreshDriver::Tick(int64_t aNowEpoch,
   // anchor changing.
   nsXULPopupManager* pm = nsXULPopupManager::GetInstance();
   if (pm) {
     LOG("pm->UpdatePopupPositions()");
     pm->UpdatePopupPositions(this);
   }
 #endif

-  UpdateIntersectionObservations();
+  // Skip chrome animation case (busy throbber and/or loading indicator)
+  // which is not a reason to trigger any observing.
+  if (!mozilla::dom::IsChromeURI(mPresContext->Document()->GetDocumentURI())) {
+    UpdateIntersectionObservations();
+  }

   /*
    * Perform notification to imgIRequests subscribed to listen
    * for refresh events.
    */

   for (auto iter = mStartTable.Iter(); !iter.Done(); iter.Next()) {
     const uint32_t& delay = iter.Key();

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Version: SeaMonkey 2.53 Branch → SeaMonkey 2.53
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: