1584803 - Tracking bug for build and release of SeaMonkey 2.53.1 Beta

Status: RESOLVED FIXED

(SeaMonkey :: Release Engineering, enhancement, P1)

Description

[Frank-Rainer Grahl (:frg)]

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

This is a tracking bug for Build and Release of SeaMonkey 2.53.1

We expect an actual release on tba.

Comment 1

[Frank-Rainer Grahl (:frg)]

Attachment: 1584803-versiondisplay-2531b1.patch

Indicate that this is a Beta version.

Comment 2

[Ian Neal]

Comment on attachment 9097203 [details] [diff] [review]
1584803-versiondisplay-2531b1.patch

[Triage Comment]
I presume we don't want to expose it in the UA string?

Comment 3

[Frank-Rainer Grahl (:frg)]

I presume we don't want to expose it in the UA string?

I would rather not want to mess with the ua string any more but not sure if we need to change it so that the project website can identify it. Maybe changing the startup url too?

Comment 4

[Frank-Rainer Grahl (:frg)]

Attachment: 1584803-lightning-calendar-253.patch

Currently needed for 2.53 only. A revised patch for 2.57 with the parts from Bug 1569539 might be needed for 2.57 later. Spit it now or do it then?

Comment 5

[Frank-Rainer Grahl (:frg)]

Attachment: 1584803-sm-tempfix-60.patch

Temporary fix for print preview only. Best would be to either fix it right before or after Beta 1.

Comment 6

[Ian Neal]

Comment on attachment 9097736 [details] [diff] [review]
1584803-sm-tempfix-60.patch

>+        let iframeDoc = document.getElementById("content").contentDocument;
>+        // eslint-disable-next-line no-unsanitized/property
>+        iframeDoc.documentElement.innerHTML = printContent;
>+        iframeDoc.title = settings.title;
>         printContent = "data:text/html," + encodeURIComponent(printContent);
Does the above line do anything now?
>-        document.getElementById("content").src = printContent;
>+        // document.getElementById("content").src = printContent;
Does a comment need putting in about it being a temporary fix?

r/a=me with those answered/adressed

Comment 7

[Ian Neal]

Comment on attachment 9097735 [details] [diff] [review]
1584803-lightning-calendar-253.patch

>+++ b/calendar/lightning/lightning-packager.mk
>@@ -20,62 +20,24 @@
> include $(MOZILLA_SRCDIR)/toolkit/mozapps/installer/package-name.mk
> 
> XPI_STAGE_PATH = $(DIST)/xpi-stage
> _ABS_XPI_STAGE_PATH = $(ABS_DIST)/xpi-stage
> ENUS_PKGNAME=$(subst .$(AB_CD),.en-US,$(XPI_PKGNAME))
> XPI_ZIP_IN=$(_ABS_XPI_STAGE_PATH)/$(ENUS_PKGNAME).xpi
> 
> 
NIT: Do we still need a double gap here?

LGTM r/a=me

Comment 8

[Frank-Rainer Grahl (:frg)]

Attachment: 1584803-lightning-calendar-253.patch

NIT double gap removed. r/a+ from IanN retained

Comment 9

[Frank-Rainer Grahl (:frg)]

Attachment: 1584803-sm-tempfix-60.patch

Comment added and dead statement commented out plus retested. r/a+ from IanN retained

Comment 10

[Frank-Rainer Grahl (:frg)]

Attachment: 1584803-sm-tempfix-60.patch

Corrected tempfix as per irc discussion. r/a+ from IanN retained

Comment 11

[Frank-Rainer Grahl (:frg)]

Attachment: 1584803-version-beta1.patch

[Approval Request Comment]
Regression caused by (bug #): --
User impact if declined: stupid ua sniffing from sites like github break the browsing experience with SeaMonkey
Testing completed (on m-c, etc.): 2.53
Risk to taking this patch (and alternatives if risky): add-ons might misbehave but we fixed the distributed ones. Sites wanting later Gecko features might break but there are very few things not in 2.53 compared to 2.57 and for these sites a custom ua can be used.
String changes made by this patch: --

Comment 12

[Ian Neal]

Comment on attachment 9114397 [details] [diff] [review]
1584803-version-beta1.patch

[Triage Comment]
LGTM r/a=me

Comment 13

[Dmitry Butskoy (:buc)]

Downstream distributions need 4 patches from bug #1341234 (to build with system nss/nspr libraries).

Comment 14

[Frank-Rainer Grahl (:frg)]

(to build with system nss/nspr libraries).
I will add them asap. Please make sure to pass -disable-stylo and -disable-webrender:
ac_add_options --disable-webrender
ac_add_options --disable-stylo

Might even succed then without it.

Comment 15

[Dmitry Butskoy (:buc)]

(In reply to Frank-Rainer Grahl (:frg) from comment #14)

(to build with system nss/nspr libraries).
I will add them asap. Please make sure to pass -disable-stylo and -disable-webrender:
ac_add_options --disable-webrender
ac_add_options --disable-stylo

Might even succed then without it.

Builds fine with the patches applied (ie. both with stylo and system nss/nspr).

BTW, most downstream problem is the rust version.
For example, Fedora uses (and will use) the latest one, which is rust-1.40 for now . If the code is not ready for it, downstream will be forced to either delay release, or use a bundled rust version to precompile at the build package time (not sure what dependencies to be bundled too it requires then...).

Comment 16

[Frank-Rainer Grahl (:frg)]

I added the patches from Bug 1341234 to the beta 1 source branch. Please disable stylo and webrender in distributions builds. This is known broken. For the next version we will disable them by default.

Rust is a mess. Not sure if even ESR 68 can be compiled with 1.40. In any case you can install more than one toolchain. We are using 1.36 for 2.53 right now. You can just install 1.36 with rustup and set it for building as rustup default 1.36.0-<architecture> i.e. rustup default 1.36.0-x86_64-pc-windows-msvc for Windows. Bill is doing this under Fedora so you can ask him: http://www.wg9s.com/comm-253/

Comment 17

[mac198442]

Obviously he meant to say rustup default 1,36.0 ... in above comment.

Comment 18

[mac198442]

I have bot current stable and 1.36.0 installed and do "rustup default 1.36.0" for all seamonkey builds and "rustup default stable" to build current mozilla-central.

Comment 19

[Frank-Rainer Grahl (:frg)]

Sorry mac is right. 1.36. I am doing the same for central and 2.53 / 2.57

Comment 20

[Dmitry Butskoy (:buc)]

(In reply to Frank-Rainer Grahl (:frg) from comment #16)

Please disable stylo and webrender in distributions builds. This is known broken. For the next version we will disable them by default.

I perform test build under CentOS-7 environment. Without any specifications, webrender is not built, stylo is built but disabled by default ("layout.css.servo.enabled" appears "false"). Does it looks correct for a distribution (ie. build with stylo, but disable it by default), or better disable it completely for now?

Comment 21

[Frank-Rainer Grahl (:frg)]

or better disable it completely for now?

Better disable both completely unless you want users playing with the config turn it on and receiving bug reports :) Stylo is not ready for release in 2.53.1.

I am a bit busy this week. Might make sense to upload the official mozconfig files used for building. If IanN does not beat me to it I will do it over the weekend.
If you build questions feel free to join irc://freenode/SeaMonkey. Can't guarantee an immediate answer but we read the logs and respond later.

Comment 22

[Dmitry Butskoy (:buc)]

Current gitlab source is not compiling with upstream rust-1.37.0-x86_64-unknown-linux-gnu (but according to the latest StatusMeeting rust-1.37 should).

Comment 23

[Dmitry Butskoy (:buc)]

Forget about the previous comment -- just a hard day. :)

Compiled fine with the upstream rust-1.37 under x86_64-unknown-linux-gnu.

Whereas this resolves rust-version mismatch issues (while SM is not ready for the latest rust), AFAIK any Linux downstream dislike (even very dislike) the use of bundled "binary" things to build the package. Since rust itself is bootstrapped (compiled by some previous version of rust anyway), such a situation with SM can be accepted as an exception, but anyway, compatibility with the current downstream' rust-1.40 would be a best thing.

Comment 24

[Ian Neal]

Attachment: mozconfig files for linux/macOS

Comment 25

[Frank-Rainer Grahl (:frg)]

Attachment: monzconfig files and build scripts for 2.53.1 beta 1 Windows builds.

Comment 26

[Frank-Rainer Grahl (:frg)]

but anyway, compatibility with the current downstream' rust-1.40 would be a best thing.

Rust is still a moving target and even Firefox ESR could not always be build with the latest versions. We try to fix the compatibility issues in a later release. For now 1.36 is the official supported release for 2.53.x. 1.37 works because we fixed it in Bug 1580697 for our beta branch only.

Comment 27

[Stefan [:stefanh]]

Comment on attachment 9121719 [details]
mozconfig files for linux/macOS

Expanding the .tar package just gives me an empty folder. Is it possible to upload the .mozconfig files as plain text attachments?

Comment 28

[Frank-Rainer Grahl (:frg)]

Expanding the .tar package just gives me an empty folder.

They start with a . I think finder does not display these in default mode.

Comment 29

[Ian Neal]

Attachment: mozconfig-1_b1.i686

Comment 30

[Ian Neal]

Attachment: mozconfig-1_b1.x86_64

Comment 31

[Ian Neal]

Attachment: mozconfig-1_b1.mac

Comment 32

[Stefan [:stefanh]]

Thanks :-)(In reply to Frank-Rainer Grahl (:frg) from comment #28)

Expanding the .tar package just gives me an empty folder.

They start with a . I think finder does not display these in default mode.

Ah, right. Anyway - thanks Ian for uploading them in plain text :-)

Comment 33

[Dmitry Butskoy (:buc)]

Attachment: seamonkey-2.53.1-flash.patch

Fix flash for 2.53 beta1.

There is some obsolete statement in the code, which prevents flash plugin to be loaded.

The test page is https://get.adobe.com/ru/flashplayer/about/

It will be strange if we stop supporting Flash plugin while Firefox still supports it.

Comment 34

[mac198442]

(In reply to Dmitry Butskoy from comment #33)

Created attachment 9123145 [details] [diff] [review]
seamonkey-2.53.1-flash.patch

Fix flash for 2.53 beta1.

There is some obsolete statement in the code, which prevents flash plugin to be loaded.

The test page is https://get.adobe.com/ru/flashplayer/about/

It will be strange if we stop supporting Flash plugin while Firefox still supports it.

I cannot reproduce any issue here what operating system and architecture (32 or 64 bit) are you seeing this under?

Comment 35

[Ian Neal]

Comment on attachment 9123145 [details] [diff] [review]
seamonkey-2.53.1-flash.patch

Not sure what you are trying to achieve here, as this method is just getting information about a plugin, has been around for over 10 years and the bit you are removing is to do with Java applets.

Comment 36

[Frank-Rainer Grahl (:frg)]

Comment on attachment 9123145 [details] [diff] [review]
seamonkey-2.53.1-flash.patch

Support for this was removed in Bug 1279218 but unless it throws it should always be false and ineffective now. Coincidentally I filed bug 1611678 over the weekend. Removes it and other cruft. Planned for 2.53.2

As Mac and IanN I am not aware of Flash not working. No plans to kill it until Fx and Chrome do either.

Comment 37

[Dmitry Butskoy (:buc)]

(In reply to mac198442 from comment #34)

(In reply to Dmitry Butskoy from comment #33)

There is some obsolete statement in the code, which prevents flash plugin to be loaded.

The test page is https://get.adobe.com/ru/flashplayer/about/

It will be strange if we stop supporting Flash plugin while Firefox still supports it.

I cannot reproduce any issue here what operating system and architecture (32 or 64 bit) are you seeing this under?

Linux 64-bit.

I've discovered that the issue takes effect when "ask to activate" only. With "always activate" (as I guess in your test case) all is OK.

Sorry for the little confusion here.

(In reply to Ian Neal from comment #35)

Not sure what you are trying to achieve here, as this method is just getting
information about a plugin, has been around for over 10 years and the bit
you are removing is to do with Java applets.

I see in error console:

Error: ReferenceError: HTMLAppletElement is not defined
Source File: chrome://communicator/content/bindings/notification.xml
Line: 543

The patch fixes it for me. Note "ask to activate" should be set for the test case.

(In reply to Frank-Rainer Grahl (:frg) from comment #36)

Support for this was removed in Bug 1279218 but unless it throws it should
always be false and ineffective now.
I mean that this HTMLAppletElement statement remaining forgotten in the comm branch. Its presence causes the issue when user uses "ask to activate" for flash plugin.
Coincidentally I filed bug 1611678 over the weekend. Removes it and other cruft. Planned for 2.53.2

OK

Comment 38

[Dmitry Butskoy (:buc)]

Successfully built with rust-1.40 (stylo and webrender disabled), on CentOS-7 Linux.

It just requires to update "mozilla/third_party/rust/url" to 1.7.2 (copied it from Waterfox-classic source, since they advanced a bit longer in backporting rust code), and to apply some drop-deprecation patch.

Since it turned out to be suspiciously easy, could someone more experienced look at it?

Comment 39

[Dmitry Butskoy (:buc)]

Attachment: seamonkey-2.53.1-rust-wf-1262.patch

It is https://github.com/MrAlex94/Waterfox/commit/617493ea44cd5599bb1bd2163611d3244afce947

Comment 40

[Dmitry Butskoy (:buc)]

Attachment: seamonkey-2.53.1-rust-url_1_7_2.patch

Update to url-1.7.2 (derived from Waterfox as well)

Comment 41

[Dmitry Butskoy (:buc)]

The patched code still compiled fine with rust-1.35, ie. no regressions if old rust is used.

Comment 42

[Frank-Rainer Grahl (:frg)]

I think we are done here. Final has been built. I leave a few dependent bugs open because they have no final 2.57 fixes in the patch queues yet.

Comment 43

[Dmitry Butskoy (:buc)]

I create special bug #1617782 for rust stuff.

With url patch splitted, and new patch for rust-1.41 .