welp, Gaggle Docs finally broke our non-Chromed browsers

trying to load a spreadsheet and I get trapped in a endless cycle of "Something happened, we've reported the error to Google so we can ignore it" JS alerts

fortunately no need to kill the browser to escape, but still...

not the first time

but is it the last time

bloop

Good morning #SeaMonkey

nsITobin blarb

I feel like this impl is improper .. not that it is wrong just from a strict sense improper.. Like using Services.jsm from an xpcom component seems incorrect i should be quering the actual component using xpcom not involving the jsm loader until i need to use the InspectElement code and even that I am not sure why its a jsm and not just part of the component.. The lines are blurred lol

it does work well though I been using it for years has really been helpful

nsITobin for obserer you can use Services.obs.addObserver and .removeObserver

I suppose it doesn't matter not like I retained pre-gecko 2.0 compat in it like the inspector commandline hander still has

and depending on the future all xpcom components might be jsm'd lol

I can get behind registering some jsms as xpcom components but not static registration..

if that seems like a good idea at some point

nsITobin IanN_Away cleaned out DOMi when we integrated it. At this point it is 2.53 only.

yeah frg_Away this component like so many like it are built by copying pasting and modifing across several points so yeah if the thing is to favor Services.jsm over xpcom invocation then that is fine

The old method still works but we prefer Services use. Much cleaner looking and internally it does the same anyway I think.

I'll switch the component over to Services.obs also dunno why it is calling weekreference

Services.jsm does just create an instance of the xpcom component ye later on when services becomes an established global i think they just reimpl in cpp pretty much the same and then expose it ..

wrt wekref don't know either

I guess one of the previous forms this component had used it.. likely abp

I'll revise the patch

with the power of mq

frg_Away: it looks like every component HAS to have a QueryInterface as part of its object.. most stuff seems to basically put weakreference in when there is nothing else

nsITobin thank for the info

i am not sure 100% yet but not having it makes it fail to load and this is what surrounding code seems to have when nothing else

i get one of those long int error values

frg_Away: why does seamonkey think the domi startup component I just unapplied and rebuilt still exists?

nsITobin might be cached and needs a restart?

looks like dist/xpi-stage is being updated but not the xpi file in dist/bin/extensions if already existing

this is a consiquence of not purging dist/bin every time you build

the drawback with doing that is each rebuild will have to go through all the xpidl files if it was changed back to how it used it be

so its a trade off between faster rebuilds or actually updated rebuilds

I think some later build patches fix this but not there yet

there it is

which make backend is it using

gah more moz automation moz artifacts moz release engineering .. what is so wrong with build machine produces builds.. see if they work.. and shipping them lol

v2 patch is attached to Bug 1912354

nsITobin will take a look tomorrow. nn

there I have recompiled the vmware modules

hopefully the network stack won't take a crap and take out the system bus

I have a new media query for the standards.. prefers-reduced-bullshit indicating your preference for reduced bullshit can be used to say, have paginated pages instead of endless scroll-wait-load-scroll or say have normal size fonts and good readablity, and don't want to be offered services first party or otherwise

Let's make it happen!

:P

and have any ads not be mixed in with content but on the side or the top

hi tomman