so because when I have BinOC/Central (gogs) open to the world it keeps getting hit in VERY specific ways that knock it offline.. of course if that happens while I am updating my repos it will cause corruption.. So how I plan to solve this issue is to move gogs to another subdomain leaving it login-only and then expose the bare repos to the web which will allow http cloning no problem.. Then to allow public browsing via a new system that just queries

the bare repos but not insanely complex-wise.

hi nsITobin

good morning frg_Away

just prepping to build central since I already cloned and re-patched comm-central see where we are at with the patches already in.

then see what remains from my adhoc stuff and how it can be applied to bugs

real life took over lately a bit more and also tinkered with some Thinkpads from the ebay scrapyard but will do 2.54.20b1 next. Just tossing a coin if I should align places more first with 2.57.

you said you'd be focusing more on non-sm stuff this week

yeah

for places i'd say ehh.. go with newest that works.. as wholesale as possible

i mean its gonna be the library window going forward regardless .. always was just hidden better so why not make THAT bit as easy as possible to have up to date and up.. date

frg_Away: one of the reasons I have been so against Firefox 4+ in-content junk is because SURE YEAH you can open it in-content or even spawn a window in SeaMonkey but its not really seamonkey-LIKE.. the Library at least is a window in a kinda super-manager state so it works.. Think Add-ons Manager .. the Aviary design tho had that mac icon header was a window in a super-manager sense so it worked..

where about:addons not so much..

truth be told the placesui should have been in toolkit for everyone to use.. just like js downloads ui.. Especially seeing as largely everyone just copies and lightly modifies the frontend impl when Mozilla made sweeping backend changes

anyway yeah why not update places to the max .. though it might be easier if the Go Menu fully becomes the History Menu in the same way Firefox did

and might need more bookmarks toolbar refactoring.. I dunno I have historically tried to stay bookmarked well away from places ;)

.. that might not be a good thing depending on context

nsITobin I think the problems I had with drag and drop are out in latest builds but still not at 2.57 level.. I removed to old sync apis but anything addon not working now probably didn't work before for a few years now.

i have noticed the add-ons manager thinks themes are restartless and the doorhangers don't show install progress anymore and seem .. out of sync with the add-ons manager

well the doorhangers do

anyway

Didn't pick anything here lately and IanN_Away neither I think. add on manger in a window is broken for sure. <<tossing a coin if it should be removed or fixed

Isn't in the way so can be kept for now I think

well i see several general paths the project could take .. Here is my list .. some of them are crap.

Mozilla-Current as a Thunderbird with Navigator Webapp Suite.. 102 fork engineering XBL back in along with full skins and opening the add-ons manager back up to toolkit-style extensions.. the wilderness between 68 and 91.. and there is always going to war with the Moon over the Unified XUL platform.. and continuing with the current codebase by finding every way to either make porting easier including walling off toolkit components that change and

re-assimilating it back comm to get it out of the way so it can be suited to the .. suite.

It's nice to have options.

of those 102 and staying with 2.53 seem MOST viable with thunderbird navigator webapp suite being HALF viable as it is a major gamble if anyone would even accept such a thing.

liberal use of #ifndef MOZ_SUITE and if CONFIG['MOZ_SUITE'] I belive can save a lot of headaches regarding app UI needing sync'd to toolkit backend UI components

if not CONFIG*

okay.. brand.ftl was added in bug 1424683 and ported to thunderbird because of 1469684 .. we need it because toolkit is part of Firefox not a platform..

so does that mean .. new bug? and is it a port of anything? because while yes it isn't for any reasons mozilla or thunderbird did it for..

IF I go to 102 I can go the central and its a sh*t show after about 58. You die of old age trying to fix things up xul and xbl. Been therre tried that with 2.57

^to central

well I wanna know why can't XBL just be added and hacked to just translate to either xul customelements

or whatever html thing it needs

may even be doable from javascript.. overlays are

some XBL facilities got directly changed to be shadowdom bits

tomman: organization account works for me (I can get to OWA), but the login process, while not asking for credentials, and after all the "enable CSS transitions temporarily" and "jump through the hops in noscript to make it work" wanted to steer me through "is this still correct" for the recovery information...

i.e. I still get the old outlook web access after all of that

didn't check via M&N

testing setup is currently less than optimal here, for a quick check I could check a free (hotmail) account, it seems to work, i.e. I can load messages and check content of folders

frg_Away: in any event I feel the best thing for mid-term survival and sustainability and user retention on the current codebase is either the UI XUL and SeaMonkey/early Mozilla-y bits need to be greatly enhanced and fixed up to near perfect order or we need always progressing webcompat.. and enough UX polish to distract from lacking webcompat by the glare.

webextensions? are they desired in a 2.53 codebase?

tomman: (in other words: in the browser, I can load old-style OWA in an org account after dealing with the login process; in M&N I can connect to "hotmail")

nsITobin webext works for a firefox there. Still missing some stuff but not a priority. Goal would be co-existance but with manifest v3 I don't care about them much longer.

frg_Away: webextensions are not realistic in a xul ecosystem

you don't and won't ever have enough apis or webcompat to make it worthwhile to anyone

and it requires massive amounts of additional new code to create the api hooks for webextensions into every frontend component

which is not possible when the backend continues to change

so functional webextensions is never gonna happen and any attempt is foolish what I need to know is how much of it from an add-ons manager perspective is important

currently dictionaries work snd themes should be because lightweight themes are gone. Further stuff is prio 9999 anyway :) js css #1 media #3

lightweight theme provider code is gone or just the fact the personas them selves are gone now

oh its still there yeah

ok

never ported the theme stuff.

those jerks xr.thereisonlyxul.org/seamonkey-2.5…lkit/content/widgets/general.xml#67

such the wrong way to do this

hi tomman how goes it