darktrojan: Hi. Nothing broke, so I'll leave it to you now.

okay

bye

My add-on "Bugmail (fixed version)" is broken :-(

No idea how it broke.

are you surprised though?

yes

in TB 60.

oh

I believe it worked at some stage

now this fails

var xml = parser.parseFromStream(input, "utf-8", input.available(), "text/xml");

I get

some security error, something mumbling about a null principal

in later version there is forceEnableXULXBL()

perhaps the bugmail itself changed

which we use in Calendar

no

The first display is fine

display of the header is fine

hitting "Update" is fine

but getting the XML from the cache and trying to parse it stopped working.

:/

it is that line that fails

And I'm sure that worked at some stage in the 60 cycle

Let me get 60.0 and check

I'll be back.

darktrojan: So now it says: XML Parsing Error: not well-formed

Location: moz-nullprincipal:{eb526566-049b-4df1-8326-bc179c2530d4}

Line Number 1, Column 1:

and if you look at the IDL, it mentions a principal for the document the parser creates.

why would a parsing error have something to do with the principal, unless it's trying to load some other document too

good question, let me try 60.0

darktrojan: you win, 60.0 doesn't work either any more

well that's something

not something useful

I don't know when it stopped working.

But I don't think it stopped working when I switched to TB 60 mid last year???

maybe something to look at later today ;-)

like I said, is it the bugmail itself?

or how it's cached

yes, I need to dump out what goes into the cache

cache shouldn't have changed

tried a really old message?

no

let's try that

I have it going back to, 2010

I last messed with the add-on in Feb 2018

must have been working then

hmm, fails on bugmail from 2011

OK, I'll look at it later, bye.

!seen rjl

mkmelin: When is rjl coming back? We have work for him, check the tree to see it.

jorgk: hopefully should be back soon

sorry, that's what you said 10 days ago and also two days ago.

"hopefully" and "soon" are not two words that let us organise anything, see me recent e-mail.

jorgk: sickness is weird that way...

heya

jorg: the error you see is because the XML is empty, you Need to check, why the XML is empty

hmmm, not happy with bug 1525376

jorgk: travelling in Spain?

not travelling

I have a second residence here

jorgk: nice

why are you asking?

It says jazztel.es on the nick, yes

jorgk: just spotted you were signed in from a spanish domain name

I was going to say, I thought you lived in Deutschland

jorgk: Have you fixed your XML error from this morning? I usually see that error, when the XML I want to parse is empty...

jorgk: Have you fixed your XML error from this morning? I usually see that error, when the XML I want to parse is empty ...

Yes, indeed, thanks for asking.

There was a problem with storing the result in the cache

as a result, I tried to parse something empty.

Bugmail 4.3 finally works.

nice!

and if I had time, I'd check when it broke.

jorgk: Hi, little question following your comment from yesterday considering formats in Thunderbird. I don't want to continue on the bug if it's really offtopic. I'm referring to bugzilla.mozilla.org/1426907#c122 and then to comment #2. I quickly went through as there are many comments, but as you can see on framapic.org/Bs7KDXzJohOx/gFarP8pDYXCm.png the only

possible choices are US English. Couldn't just this be manually set by user *independantly from language*. ie. tying this to language leads to odd inconsistencies like for example having everything in English, excepted day of the week and mond month in French for example, because time/date format were selected as French ones

hi

you're saying that instead radio buttons, you want a drop-down with all possible localed?

locales?

that would also be doable.

I'm surprised you only get en-US.

Well, it's something possible, but would still be tied to the language. you could also consider letting the user setting what and where does he want to put dd yy, yyyy, mm, hh, and so on as well as separators

also an option.

We just follow whatever Firefox deems fit

and FF only should very few dates around the UI.

Or yes, use the same as somewhere else in the system, but for example for my current case (ArchLinux, Gnome), I get 24H time and everything is with en_US (the strangest in this being that I don't even remember setting something specific for this)

I think what we have is fine, works well on WIndows, only all those different Linux distros cause endless problems

Might be tied to this: `lrwxrwxrwx 32 root 16 Oct 2018 /etc/localtime -> /usr/share/zoneinfo/Europe/Paris`, but I would be surprised that it comes from this though

So, basically, Linux users just have to deal with it and that's all? :|

(there may be better support for the various LC_ vars in the future, but currently the system just uses one locale for languages and one for formatting)

Sorry, it's not that Linux uses "just have to deal with it". Linux users using "hand-made" distros, like Arch, will also need to hand-make that.

Well, I checked, but curiously LC_TIME is not set for me

jorgk: Okay, hand-made it. But there's no setting to do it right now, isn't it?

As I said in the bug, we have people in Finland and Slovakia on "mainstream" distros, and it "just works" for them.

(-> searchfox.org/mozilla-central/sourc…locale/gtk/OSPreferences_gtk.cpp#34 so based on that you could figure out what it falls back to)

I have no idea why your setup only detects en-US. And that's surely not for us to debug.

ah, there's also firefox-source-docs.mozilla.org/intl/locale.html# that documents how the fallback chain works

Well, and yet, that's only thunderbird offering this choice ;(

talk to mkmelin and ask him how he does his Swedish/Finish based on en-US

(I use de-CH for formatting and en-US as UI language)

freaktechnik: And what's the language days and months are displayed with?

german, because that's what the date formatter is using.

ah wait, no english

(in lightining)

but in timestamps that were formatted I get the german ones.

So, it looks quite inconsistent

(so for example the day titles in the events sidebar)

that's not a decision problem though, that's a problem from which resolved locale is being used.

(and I totally understand why it behaves that way)

Hi KaiE, just reading your comment on bug 1518185. Out of curiosity, how far along is that integration?

I don't get it, how can two different parts end up using different languages to display the same thing. And how it can be considered as normal behavior :/

Porkepix: I just set $LC_TIME to sv_FI.utf8. The locale you set it to needs to exist on your system. There's info in the bug about how to generate it if it's not set already

How pressing is it to figure out the proper UI?

clokep, we're trying to get it into 68

So fairly pressing? :)

mkmelin: What's strange here is that for example Gnome is set to en_US, and show me 24H time, despite LC_TIME being unset. and that Thunderbird is not displaying the same.

I think mkmelin would say yes :)

Porkepix: I'm not saying it's perfect behavior, but it's essentially me saying I want text to be english and dates to be german, right? So lighting gets the translated text for the day name and the month, thus uses my text language. But when lighting says "I want to format this date in a long form" it uses my date language and in the long form it may include day names etc.

KaiE: Cool. Is there any UI mock-ups or anything that florian and I can take a look at?

I know he has some opinions about this UI! I probably do as well, but haven't wrapped my mind around it yet.

clokep, I don't want to give you anything that's broken. Once I have completed the porting in an initial, but complete working state, I'll let you know. I might have that next week.

freaktechnik: Yeah, but you just said that in some places, English words were used. I don't get why format would have to be bound to language :/

clokep, KaiE: without knowing too much about the UI and how OTR works, maybe this should be designed in a way to also accomodate native e2e encryption from the protocol (thinking of matrix specifically, but also things like gpg over xmpp)

Porkepix: "So lighting gets the translated text for the day name and the month, thus uses my text language." the actual formats are always in de-CH, it's only sometimes names that aren't and sometimes are, depending on where the name is coming from.

freaktechnik, we're porting an existing UI from the old Tor Messenger, so currently we aren't inventing.

(or designing)

but yeah, we're open to suggestions

freaktechnik: Yes, it should.

KaiE: bringing it up related to our discussion yesterday about the interface, since the protocol may be interested in also giving a state if it has native e2e encryption. But as I said, I don't know what OTR actually does.

*state of

(Although I think there are newer things people use than GPG for XMPP, but I get your point.)

clokep: pretty sure there's tons of things you can do over xmpp for e2e encryption

freaktechnik, in the meantime, I no longer need that extension from yesterday. Nevertheless, I was only trying to save some derivation of state from other sources. But in the meantime I've figured it's easier to always look at a set of variables to derive the state when switching tabs.

freaktechnik: Yeah, let's not get bogged into that. :) We're saying the same thing -- regardless of the protocol and mechanism used, we would want some sort of consistent UI.

freaktechnik: I guess that mixed-up languages like that would be terrible also when it happens with one RTL language and one LTR language

Porkepix: agreed, but that's an entirely different issue that affects very specific parts (chat archives and lighting are the main ones I've noticed so far).

Anyway, no point in trying to untie format from language as of now, that's not possible right now nor possible anytime soon?

s/possible/planned/

freaktechnik: Ah bug 1237416 is the one I was thinking of though. :)

it is untied? It just uses LC_TIME and not any other var?

clokep: gajim has native pgp though, which is why I thought of that.

Yeah, makes sense. :)

There's a whole bunch.

freaktechnik: What I mean is that you still set the format by selecting a language or a country rather than by letting user design the format he want. (Btw, tried LC_TIME, but didn't work, probably due to locale.gen. Still my DE can deal with it as it is)

clokep, I could give you a patch where the notificiation bars aren't working yet (seems to be broken last time I asked), and the dialogs aren't working yet. But the chat interaction seems to work now, including the state button and its menu

clokep, what OS do you use? Because we cannot yet integrate the OTR library and gcrypt library, manual setup is necessary for those libs

clokep, well, and I'm developing based on an older snapshot. I don't know if my patch builds with the latest trunk. Magnus warned me that chat is pretty broken on trunk, that's why I'm staying with my working snapshot

porkepix: usually applications follow the formatting the OS provides, so you choose in the OS.

freaktechnik: Yup, but here that's not the case :p

KaiE: I'm on macOS.

I'm fairly certain I have the proper libraries installed already via homebrew.

ok

And I think chat is fixed on trunk now.

ok. Let me pull

Well, no need to mess up your workflow. :)

freaktechnik: Easy to see from here: framapic.org/kISTZuiok8e9/oj3hnV1lL6f0.png

clokep, what's the status of convNotificationBox ?

KaiE: Is that broken?

I don't remember seeing a bug about that.

clokep, it was broken a week ago. Incoming buddy contact requests weren't showing

clokep, bug 1532967

Huh. Looks like I did see it. :-D

KaiE: Then yes, that's still broken and no one has looked into it.

mkmelin : ping

Porkepix: that image isn't loading for me, so no not easy to see ;) But as jorg had already pointed out, this is most likely an issue with the infrastructure inherited from Firefox, which is the bit documented in the docs link etc.

freaktechnik: Oh? I can see the image here

clokep-M, I've updated the patch in phabricator.services.mozilla.com/D17691 - it's working with current trunk

clokep-M, FYI: try build with latest OTR work-in-progress patch here: treeherder.mozilla.org/#/jobs?repo=…c2e9b9c44ffb06d08b55b4f0a6e49f66b36

clokep, the OSX try build has completed

you'll need to use the config editor and set chat.otr.enable to 1

oh, eslint is complaining because it now exists in chat :D

freaktechnik: Yep! :) We can disable it for certain directories if that helps get stuff landed.

it'll probably need to know about that worker being a worker in that patch there, for example.

jorgk: around?

yes

jorgk: I was looking at bug 1533085... Did the hamburger menu show up before my patches? I backed out both of them and it doesn't seem to make a difference

hmm, I haven't tried myself, but in the bug it's recorded that backing them out fixes it

maybe some later changes worsened the situation

if you want to used real machine power, go the changeset before and the matching C-C changeset

but I don't have to tell you how bisection works ;-)

jorgk: hmm, ok, no wonder I wasn't finding anything suspicious: mozilla/releases-comm-central c04c2f1

jorgk: Ok, probably also reverting that will presumably fix it, and I can actually debug it.

not really

those changes didn't affect the hamburger

jorgk: well, they didn't because my patches made those attributes useless

jorgk: but that's why backing my patches out doesn't fix the menu anymore :)

jorgk: mozilla/releases-comm-central c04c2f1#diff-c22858272ed4b81d47fbd1a1f1bd0059L13 is what used to make that menu work

OK, I see

best bet is to revert to before all those changes

jorgk: can we revert that patch? It's easier to track what needs to be fixed if that's in, and that patch should be basically harmless I'd think.

don't understand

revert as in back it out officially?

jorgk: yeah, that way we can remove display attributes one by one, as we fix them

jorgk: no big deal if not I guess

well, you can back it out locally

jorgk: ok, that sounds fine, I just don't think I have time to fix all of them now, but I'll fix the ones I see around

I was going to suggest you go to treeherder.mozilla.org/#/jobs?repo=…ce8f05d07cc6672ed50b5bf7d96658f2479

that's C-C at 392d6ce8f05d

and ...

M-C at 4ab143dde4dc3424cfedc74b3648fbf2e4

that's the totally busted stage after your change landed

you're not using HG?

jorgk: cinnabar, but I can checkout hg commits, so no worries

emilio: xxx removed all the stuff that needs fixing.

emilio: What do you mean by "fixing".

that stuff doesn't work any more, right?

jorgk: right, I mean that for each of those we need to either find a replacement, or prove they're useless (I found a couple of those that were)

jorgk: I just pasted it on the bug to not lose track of them

yes, some replacements have already landed

but ideally we don't want to "replace" all the toolbar button menus since we used them a lot

jorgk: Yeah, no worries, I got a fix for those

most prominently on the hamburger, so if that doesn't work, it takes down 22 tests :-(

jorgk: yeah, the only thing that needs to be done really is to add type="menu" / type="menu-button" to the ones that don't work... I'll submit a couple patches in a sec

jorgk: landed a patch to help with all the <button type="menu-button"> and <toolbarbutton type="menu-button">. Sent a patch your way that fixes the hamburger menu.

Thanks, but ...

one nit, is it really - # ifdef MOZ_THUNDERBIRD

with spaces between the # and the ifdef?

and then, in the patch I had attached, you can see: bugzilla.mozilla.org/attachment.cgi?id=9049470

#if defined(MOZ_THUNDERBIRD) || defined(MOZ_SUITE)

well, I guess SeaMonkey is pretty much dead, but we like to keep them in mind

so that patch needs the M-C change, yes?

emilio: still there? ^ ^

jorgk: err, yes. Yeah, the spaces are needed (clang-format injected them). I can change it to that ifdef if you want.

jorgk: also no, the patch shouldn't need the m-c change

well, triggering another mozilla build with no real code change?

emilio: Clang really has some funny ideas, why is the ifdef further indented than the code below?

jorgk: because that whole block is inside an `#ifdef MOZ_XUL`

strange

so what does the M-C change do?

jorgk: MOZ_XUL is pretty much always true. the M-C change fixes the type="menu-button" stuff

I see

so type=menu already works, yes?

jorgk: yes

emilio: I superseded your patch since it wasn't in the right format. No offence intended ;-)

I wonder why type=menu was missing

aceman: I'm just pea counting and then I'll start a try

arshad: many tests (including attachment ones) are disabled right now, so your try runs may not show problems

Aceman is there any option other than waiting

aceman

the fixes are in queue, should be done by tomorrow morning

or you can push with the fixes

but one is for m-c

silly question: is there a good example somewhere of how to write a xpcshell test which just tests a function in a js file?

uff

test_longLines.js, just cut 95%

I haven't written that many

and mostly they were copies with heaps of async stuff, promises, etc.

test_mapisendmail.js is only a page

test_longLines.js looks like it's testing xpcom stuff... I just want to test a js file I'm writing

can you import it in the test file?

does it need to be a .jsm file?

the tests I've looked at seem to suggest so...

no

try Services.scriptloader.loadSubScript

look for exact syntax in the tree

cool, thanks for that - I've seen a couple of those about! Just wondered if there was any canonical way to test individual .js files

chat/protocols/irc/ has some xpcshell that loads plain js files I think

aceman: btw, thanks for the feedback on the RDF patches - the holdup is dealing with the feeds issue. The feeds are riddled with rdf-isms, so that's what I'm sorting out now.

yes

alta88 should be able to help you

ah yes, rss..

freaktechnik: thanks! that look a lot like what I'm trying to do

RDFXML is not my favourite file format.

I think rss is the hardest thing to de-rdf

yup - and we still need an rdf parser (for reading legacy feeds.rdf/feeditems.rdf and for parsing rss1), but I've got that covered now. The rest is mostly replacing the XPCOM-based data with plain javascript objects.

I'm still playing with replacing our networking infrastructure

oh - on the subject of testing, should I be writing mozmill tests or are mochi tests an option now? (want to add some proper gui-based tests for the feeds to sanity check the integration)

jcranmer: oh? any promising avenues so far?

bcampbell: I've got the state machine almost completely ripped out of NNTP

it's down to NNTP_LOGIN_RESPONSE, NNTP_SEND_FIRST_COMMAND, NNTP_SUSPENDED, NNTP_DONE, and NEWS_ERROR

my goal tonight is to actually rip it out completely

I've ripped out the direct use of nsIInput/OutputStream

and nsISocketTransport

the next goal after that is to fully use the generic socket infrastructure I have for server provisioning

proxy support is going to be tricky

and, finally, after all that, ripping out URLs

which will let me ask the question "what language should we do this all in?"

cool - I look forward to seeing where this leads!

I'm not planning to actually do major changes to NNTP or other netowrking features simply to lessen the burden of "we might rip this all out soon anyways"

but it might actually be usable beyond the testsuite now

sancus: Hi, does BMO work for you?

It's pretty down for me

jorgk: looks down to me, taking forever to load

so we go to bed?

!seen rjl

according to #bmo they did a prod push and broke things

it seems working again for me now

sancus: Yep, could you take a look at bug 1535183, it's a bit webby.

maybe compare to a FF build to see what's going on

um?

I'm not sure what 'a bit webby' means lol, as far as I can tell taskcluster can't find some internally generated json file?

I dunno anything about taskcluster

whats up with rjl anyway? 2 weeks seems like a long time

sick

doesn't look like it can't find some internally generated json file?

there is no reference of the file anywhere in searchfox

well, looking for the previous name

it's 404ing on chain-of-trust.json, that's an internally generated taskcluster file

[13:19:28] dylan all fixed.

so that must fall from the sky

or be part of some TaskCluster site

having found that makes you the expert now ;-)

unfortunately, even if I am the expert, I cannot help you much

because I have no access or even any idea how to access any build stuff :)

any idea where that file might come from?

the documentation says the workers generate it

Just funny, if you look at that changeset, there are no other changes

they've just changed the name

jorgk: That's because the real changes are on github, they linked them in the bug.

escapewindow/scriptworker 2fdb4f0 is the patch that changes it

So the change is that this github.com/mozilla-releng/scriptworker worker thing generates the file for whatever process

I saw that.

Taskcluster is a zillion different repos that all do stuff I don't understand, so I don't know what is going on but

but ...?

my guess is that for some reason our build isn't using the updated worker code with the new file name

I don't know if that's a reasonable guess or not, since I don't know if we manually update to new taskcluster builds or what

couldn't tell you how any of that deployment works :D

hmm, thanks for looking

I don't know what "our build isn't using the updated worker code" might mean or where we reference it.

But there have been cases where stuff needed to be fixed on github

strange it only fails for Windows

like I said, I don't know how taskcluster changes are deployed

But for whatever reason, the linked code on github that changes the file name isn't running on that build, or something else is moving the file

Hard to really debug it without being able to look at a build in progress and make changes, which I can't do