found this today on HN: jamesl.me/atto

of course, it doesn't work on Seamonkey

doesn't exactly tell what Google-esque features it requires, it just redirects me to jamesl.me/atto/notsupported.html

oh, it says something about "lookbehind in regex" not working on Apple toys, maybe it's the same on SM?

yup, the check is very simple: jamesl.me/atto/supportcheck.js

regex stuff, which curiously also fails on Safari

(hence the authors' rant, for which no other browsers exist but Chrome, "recent Firefox", and Safari because iPhones)

bug 1225665?

ah, yes, it's linked from the webkit issue linked on the notsupported page

«Considering that all modern browsers -- save for Safari/WebKit -- support regex lookbehind»

njsg atto = yapl it seems. And the site is something you can pass all day without missing a thing so no loss. Another form over function.

njsg: tomman: lookbehind issue seems to be fixed by bug 1634135. A lot of commits, but kinda new subdir mostly -- let's hope it won't be that hard to backport...

buc they imported the complete regexp parser from Chrome. This is not the hard part but integrating with Spidermonkey. I looked at it a few months ago when some other site broke. Possibly 100 to 200 patches and for the last part not easy ones.

wait, what?!

now Mozilla is borrowing code from Chrome, wow

tomman. Wonder when they will import V8 and call it a day :)

that reminds me. new month so need to check statcounter.

Down again: gs.statcounter.com/browser-market-s…p-browser-ww-monthly-202001-202107#

Not much but the trend is your friend... But next month when the Photon theme is becoming such a hit after all the naysayers have quit it will be huuuge!!!

speaking of regex stuff, remember those sites with broken OpenWeb comment forms?

like Simple Flying, among others

those have never worked since they went full-Chrome

but now, I get a different error: "SyntaxError: invalid regexp group"

it's on a bunch of minified JS from launcher.spot.im, lovely

well with basically one regexp parser having 99% merket share I bet testing is done widespread across browsers :)

ironically it's only Apple users that dare complaining... at Apple!

maybe Webkit/Safari should stagnate on purpose, if only to put a reality check on Google

noone cares about us, but if it is the browser on America's most loved cellphone, maybe things would change

I'm playing with mail "Archive" issue, bug 1718839. After applying the patch, no more errors in console. And even a new per-year subdir is created under "Archives" folder. That's all. Nothing else changed -- the mail remains in Inbox...

The same scenario with 2.53.7.1 works fine.

Could anybody confirm that mail "Archive" works as expected after applying the first patch from bug 1718839 (note it is applicable against omni.ja)?

buc you need both. It creates the folder but then hits the second error with the missing function.

frg: Hmm... Some empty-like mail is received, seems from you...

and yes, the second patch helps :)

buc nope didn't sent it. Spammer of the day maybe.

To add to it the removed function was also used for drag and drop. I never realized because the patch in Bug 515675 takes care of this. So ther might be d&d breakage too in 2.53.8.

Well, seems another issue -- when I playing with moving a mail between archive and other folders, sometimes the mail "disappeared", and a broken mail (headers only, even partial) with some garbage data (from old already removed messages) appeared instead.

This is not different from moving regular mail around. I have yet to see this but you never know. This is all new code and might still have bugs.

Would it be suitable for downstream level to revert (for a while) the changes from bug 1694760? Ie. do not "Switch to MailServices in Message Display code" for a one release cycle?

This is a bunch of bugs Main one was Bug 507601. I would not touch it. Overall it it stable or one of us whould have hit the problems sooner and I and also IanN_Away too would rather have testers. The old code had just different problems and they were harder to fix.

In ~50% cases when moving a mail from the local "Archive-->2021" folder "back" to the Inbox folder on an Imap server, the "local copy" of the Inbox's mail appears broken. (Some garbage fragment, kinda partial headers from a previously received mail etc.) The copy on the imap server remains valid.

Probably removing the "2021" subfolder and/or unexpand the "Local Folders" help to trigger the issue. Still cannot find 100% reproducible case...

Well, steps to reproduce:

send you an email to be appeared at imap server;

remove "ImapMail/" and "Mail/" directories from your profile;

start "seamonkey -mail", see your test mail;

"Archive" the mail, it then appears in "Local Folders-->Archives-->2021";

move the mail from this 2021 back to the Imap Inbox;

try to see it again there. It is broken now.

The copy on server remains OK. If you remove ImapMail/ and start again, you will see it is not corrupted.