SeaMonkey 2.33/2.33.1 have been released!

[patrickjdempsey]

Yes, there's a bug where some parts of the Findbar aren't working since Mozilla changed it awhile back... the "phrase not found" and red lettering for instance only appears on the first tab and not on others.

[therube]

Bug 973573 - Red background for unmatched search strings not reliable
And what Jiri wrote is probably the issue. (He's been right before .)

[patrickjdempsey]

Yes, I looked into this awhile back and was able to "fix" it by creating some pretty stupid listeners in a loop but loops are bad!

[Anonymosity]

Why is it that on some pages, you get the match status with the findbar, and not on others? On the index pages of this site, I see how many matches there are, but not on this page, for instance.

[patrickjdempsey]

From what I can tell, it only works on the first tab opened in a new session, with increasingly weird results using session restore. All notifications are broken in this way: matches, not found, reached end of page, etc. However, the "bonk" sound of a not found query still happens, even though the notification doesn't appear. It's weird stuff... but it's just subtle enough that most folks don't appear to have noticed at all. I probably wouldn't have noticed if I wasn't attempting to theme the red color for the not found.

[Philip Chee]

Bug 962910 Findbar only shows status messages for the original tab

status-seamonkey2.33: affected
status-seamonkey2.34: fixed
status-seamonkey2.35: fixed
status-seamonkey2.36: fixed

Bug 1146168 Find bar no longer opens with autostart or with / or ' keys

status-seamonkey2.33: affected
status-seamonkey2.34: fixed
status-seamonkey2.35: fixed
status-seamonkey2.36: fixed

[patrickjdempsey]

Awesome!

[Anonymosity]

Why do you still get the match status if the content is produced by SeaMonkey itself? If I search source code for a page for instance, I see the number of matches.

[patrickjdempsey]

Again... same reason it worked in the first tab of any window and not in subsequently opened tabs. The problem seems to be that the event listeners were only firing for that first tab. Since the View Source window is only one "tab" it worked fine. This was all broken when Firefox switched to per-tab Find.

[DJGM]

Any idea why there's been no SeaMonkey 2.34 (built upon Gecko v37) release yet? It's a bit overdue.

[DJGM]

Any idea why there's been no SeaMonkey 2.34 (built upon Gecko v37) release yet? It's a bit overdue.

No worries ... found the answers on the SM blog. Needing to upgrade the OS on the Windows build servers it would seem.
I'd donate one of my Windows Server 2008 or 2012 product keys from my old Technet subscription if that would help in
any way, but I doubt the beancounters at Redmond would take too kindly to that!

[barbaz]

Any idea why there's been no SeaMonkey 2.34 (built upon Gecko v37) release yet? It's a bit overdue.

Good question. I see that there isn't even a tracking bug.

According to https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2015-04-28#Release_Train it's due to issues with the Windows build.

(Been using "SeaMonkey 2.34" as my everyday browser on Mac OS X & Linux for some time
Only hit one snag - a snag most people would never run into at that - which I wrote about @ viewtopic.php?f=5&t=2928683 ; otherwise, works well.)

[patrickjdempsey]

Best place for news is either subscribe to mozilla.dev.apps.seamonkey or watch this page: https://wiki.mozilla.org/SeaMonkey/StatusMeetings

Last meeting was a week ago now, but this info is still current: https://wiki.mozilla.org/SeaMonkey/Stat ... r_and_Tree

So here's the tracking bug... I'm not sure what it being empty means, but perhaps Philip can fill us in on the details: https://bugzilla.mozilla.org/show_bug.cgi?id=1114876

It is likely that security patches and feature fixes will backport to a 2.33.2 release and 2.34 will be skipped. Remember this was done with 2.26.1 as 2.27 was skipped last year because of issues building for Linux.

[rsx11m]

It is rather unlikely that a 2.34 will still be released, given the issues with the build system. One would think that it's a straight-forward task to update an operating system and the compiler versions on the builders, but apparently not (at least not in Mozilla land). Let's see if the 2.35 cycle (which is starting next week already) will bring better news. Workarounds are to release a 2.33.2 with at least the security fixes, or to release 2.35 on the platforms where they can be built and either skip it for Windows or ask the community to provide those builds.

There will be another status meeting on May 12, thus after the merge, 12:00 UTC on #SeaMonkey.

[rsx11m]

(Been using "SeaMonkey 2.34" as my everyday browser on Mac OS X & Linux for some time
Only hit one snag - a snag most people would never run into at that - which I wrote about @ viewtopic.php?f=5&t=2928683 ; otherwise, works well.)

Mac OS X 10.7 "Lion", SeaMonkey '2.34pre' (self build from c-r rev ba8b3f855a96 / m-r rev 42b937b0039b; the only special option is ac_add_options --disable-eme)

Yes, the EME stuff (Encrypted Media Extensions = Digital Rights Management) currently only works for Windows (if at all, quite likely SeaMonkey is missing a bunch of at least UI patches that Firefox has already). Weird though that you had to disable it explicitly, on Linux I had no problems building without that switch (that's a trunk build, though).

Anybody who doesn't like to build on your own, the Linux/Mac tinderbox builds from the beta repository might be an alternative (though it's in general not recommended to use those for production systems; they are still automatically built without any QA after all).