### Log session started at Thu Sep 14 00:00:00 2006 ### [00:00:26] dria [dria@moz-B7FD1F7E.cpe.net.cable.rogers.com] has quit IRC: Quit: Leaving [00:01:08] bent [chatzilla-@moz-E15E31D4.hsd1.ca.comcast.net] has joined #developers [00:01:08] bent [chatzilla-@moz-E15E31D4.hsd1.ca.comcast.net] has quit IRC: Quit: bent [00:01:51] asac [asac@moz-F25DD074.adsl.alicedsl.de] has quit IRC: Ping timeout [00:02:25] Elen [El@moz-395FE35C.hsd1.ut.comcast.net] has joined #developers [00:02:37] biesi [chb@sjs-130-65-241-181.sjsu.edu] has joined #developers [00:03:05] biesi [chb@sjs-130-65-241-181.sjsu.edu] has quit IRC: Connection reset by peer [00:03:29] biesi [chb@sjs-130-65-241-181.sjsu.edu] has joined #developers [00:03:57] dougt [dougt@moz-C552EF89.hsd1.ca.comcast.net] has joined #developers [00:04:44] dougt [dougt@moz-C552EF89.hsd1.ca.comcast.net] has left #developers [00:04:51] asac [asac@moz-6C4A69C0.adsl.alicedsl.de] has joined #developers [00:10:26] josh [josh@moz-3628CCAA.mn.res.rr.com] has quit IRC: Quit: Leaving [00:11:52] myk [chatzilla@moz-7B3C332.sfo1.dsl.speakeasy.net] has joined #developers [00:13:32] sp3000 [chatzilla@F4205B63.F64F4E60.55E1D0E4.IP] has joined #developers [00:14:04] <@bz> Bernd: https://bugzilla.mozilla.org/show_bug.cgi?id=352367#c9 , right? [00:14:45] bz: https://bugzilla.mozilla.org/show_bug.cgi?id=352461 [00:16:02] bz: chris has written soemthing similiar for border collapse [00:16:33] <@bz> ah [00:16:45] <@bz> yeah [00:16:56] <@bz> this sounds like exactly what dbaron's code wants [00:17:45] I guess then this code will not show up anymore in jprof prominently [00:18:00] <@bz> why do we need to worry about cellmap repair? [00:18:15] mwu [mikew@moz-5B5E35CE.rutgers.edu] has quit IRC: Quit: Leaving [00:18:33] bz: it might be the only place where we do it [00:18:34] now [00:18:39] <@bz> ih [00:18:40] <@bz> er, oh [00:18:49] <@bz> well, wait [00:18:52] <@bz> how does the trunk code work? [00:18:57] <@bz> Does it also call GetDataAt? [00:19:05] of course [00:19:16] why it is so slow [00:19:24] <@bz> GetSortedFrames() [00:19:26] <@bz> I guess it does [00:19:57] we call cellMap->GetCellInfoAt [00:20:18] <@bz> inf->cellFrame = [00:20:18] <@bz> TableFrame->GetCellInfoAt(rowX, colX, &orig, &inf->colSpan); [00:20:19] <@bz> This part [00:20:20] <@bz> ok [00:20:41] http://lxr.mozilla.org/seamonkey/source/layout/tables/nsCellMap.cpp#2556 [00:20:53] <@bz> right [00:21:04] <@bz> ok [00:21:06] <@bz> so wait [00:21:35] <@bz> I know we have other callers of GetDataAt() with PR_TRUE [00:21:43] <@bz> We know this caller doesn't want repair [00:21:54] <@bz> So the only issue would be if some other caller does but is passing PR_FALSE? [00:22:06] no we don't know [00:22:41] <@bz> we don't know that this caller doesn't want repair? [00:23:10] bz: no we don't know that there are other places which will be executed to repair [00:23:17] <@bz> ok.... [00:23:22] <@bz> but so what? [00:23:30] remove the repair [00:23:32] <@bz> That is, any place that wants the repaired info is passing PR_FALSE [00:23:39] <@bz> er, passing PR_TRUE [00:23:53] <@bz> places that don't care about repaired info don't care whether we repair here [00:24:00] dolphinling [chatzilla@F888A381.A869895A.C2F92C85.IP] has quit IRC: Client exited [00:24:08] bz is not sure whether he's making sense [00:24:21] <@bz> I guess here's my point. [00:24:28] <@bz> Say we change the strategy to not trigger repair [00:24:58] <@bz> Where would this cause problems? In any case where someone expects repair to have already happened, right? [00:24:58] bz: https://bugzilla.mozilla.org/show_bug.cgi?id=351942 [00:25:38] <@bz> sure [00:25:40] <@bz> I read that [00:25:50] <@bz> I agree that the mechanism needs improvement. [00:25:59] once this is fixed the repair issue will vanish but still then we don't need to travel up and down [00:26:10] <@bz> I'm just not sure how that blocks bug 352461 [00:26:39] <@bz> If our iterator cared about non-originating frames, we would care... [00:26:42] <@bz> But it doesn't [00:26:56] dolphinling [chatzilla@F888A381.A869895A.C2F92C85.IP] has joined #developers [00:27:03] <@bz> and originating frame locations are not affected by repair, are they? [00:28:15] we need to have correct colspans [00:28:31] so we need corrected values here desperately [00:28:36] <@bz> hmmm [00:28:37] <@bz> ok [00:28:45] <@bz> so maybe I misunderstand what repair does [00:28:53] <@bz> Does repair affect anything other than 0-spans? [00:29:08] in principle no [00:29:28] <@bz> ok.... [00:29:41] in reality it marks also cells that it could not repair as dead so that it does not try to repair them again [00:29:48] <@bz> ok [00:30:04] <@bz> Sure. [00:30:06] thats the last big performance gain [00:30:22] <@bz> But we don't care about that, do we? [00:30:29] <@bz> That is, we just want to look at the spot right below us. [00:30:41] <@bz> If it's got cell data, great. Check whether it's originating, etc. [00:30:45] <@bz> If it's a hole, move on. [00:30:52] <@bz> because we don't care about non-originating stuff [00:31:12] <@bz> or am I missing something? [00:31:17] the second pass with the colspans on the oginating cells needs to get repaired/expanded cells [00:32:21] <@bz> can you point me to a line in the reflow branch strategy? [00:32:31] bz doesn't recall all the side effects as well as he should. :( [00:33:45] bz: the problem is the code that it has these side effects [00:33:49] line 289 [00:34:15] <@bz> So that line needs a correct |colSpan| ? [00:34:25] sure [00:34:31] <@bz> Oh, I see [00:34:44] and it gets it only for zerospans if we repaired before [00:34:46] <@bz> so for an originating cell with colspan="0" this code would screw up if we skipped repair [00:34:48] <@bz> gotcha [00:35:05] bienvenu_ [DavidBienv@moz-DA017C7B.dsl.pltn13.pacbell.net] has quit IRC: Quit: Trillian (http://www.ceruleanstudios.com [00:35:06] nice [00:35:44] the design decision is very old (troy or buster) I believe [00:37:18] <@bz> yeah... [00:39:42] yason [yason@38679F97.A3945F99.EA2C8431.IP] has joined #developers [00:41:48] no, it was the master himself.... 2000-01-31 19:23 [00:42:11] <@bz> so the way I see it [00:42:16] <@bz> for 1.8.x it doesn't matter [00:42:28] <@bz> and for 1.9 we'll hopefully get this fixed. [00:42:29] <@bz> Right? [00:42:45] this is not branchable [00:44:12] for 1.9 thats the plan, oh cool the corresponding bug https://bugzilla.mozilla.org/show_bug.cgi?id=24880 [00:45:29] hello all, any idea how to fix "Permission denied to get property XULElement.ownerDocument' when calling method: [nsIDOMXULSelectControlItemElement::ownerDocument]"? [00:45:44] Bug 352489 [00:49:01] Crash, huh? [00:49:08] WeirdAl tries to repro on Windows [00:49:10] brb [00:49:55] Uh, what's Orca? [00:50:01] WeirdAl [chatzilla@moz-538880CE.hsd1.ca.comcast.net] has quit IRC: Client exited [00:50:24] It's a screen reader [00:50:40] WeirdAl [chatzilla@moz-538880CE.hsd1.ca.comcast.net] has joined #developers [00:50:49] http://www.gnome.org/projects/orca/ [00:50:55] <@bz> ginn: who's making the call? [00:51:05] in accessible code [00:52:12] <@bz> ok... what JS is on the stack, if any? [00:52:12] oh, then I won't crash - on Windows I have --disable-accessibility thanks to a really stupid bug about VC8 freebie edition [00:52:27] <@bz> although... that's weird [00:52:27] :-| [00:52:41] <@bz> What's actually getting the exception? [00:52:51] a second [00:54:26] dveditz [dveditz@moz-46636307.office.mozilla.org] has quit IRC: Ping timeout [00:54:40] raccettura [raccettura@moz-B3D97F32.hsd1.nj.comcast.net] has quit IRC: Ping timeout [00:57:53] <@vlad> bz: got a sec? [00:58:10] http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessibilityService.cpp#294 [00:58:42] how can I find out JS on stack? [00:59:01] whimboo [whimboo@moz-EB1856E3.pools.arcor-ip.net] has quit IRC: Quit: Quit [01:00:30] rob_strong [rob_strong@moz-46636307.office.mozilla.org] has quit IRC: Quit: Chatzilla 0.9.74-rdmsoft [XULRunner 1.9a1/2006070508] [01:01:12] DumpJSStack, I believe a little bird or two told me. (When I mistakenly typed "DumpJSObject" into my blog.) [01:02:24] ss [ss@moz-21C11B32.usma1.compute.amazonaws.com] has quit IRC: Quit: brb [01:02:58] ssieb_roam [ssieb@moz-94BCB728.vs.shawcable.net] has joined #developers [01:03:26] ss [ss@moz-21C11B32.usma1.compute.amazonaws.com] has joined #developers [01:03:35] WeirdAl steps out for a late-night snack [01:03:36] ginn: debugger or c++? [01:04:20] gdb [01:04:48] ginn - oh, why didn't you just say "the spawn of Satan" :) [01:05:28] or "that Rube Goldberg device" [01:05:32] ginn: what's aNode and such in ::GetShellFromNode? [01:05:56] biesi [chb@sjs-130-65-241-181.sjsu.edu] has quit IRC: Quit: Verlassend [01:07:15] ginnn: pastebin "where" [01:07:16] aNode is nSXPCWrapped [01:08:11] crowder [crowder@moz-454FFD85.sd.sd.cox.net] has quit IRC: Quit: This computer has gone to sleep [01:08:41] madewokherd [urk@moz-63500C09.rhbd.psu.edu] has quit IRC: Client exited [01:09:59] a second [01:11:07] http://pastebin.mozilla.org/454 [01:11:37] frame 3 [01:11:38] Xanthor|aw [Xanthor@moz-B6DEAC86.w86-206.abo.wanadoo.fr] has quit IRC: Ping timeout [01:11:40] dbaron [dbaron@moz-46636307.office.mozilla.org] has quit IRC: Quit: 8403864 bytes have been tenured, next gc will be global. [01:11:52] call DumpJSStack() [01:12:07] [pastevbin output] [01:12:14] Can someone land a patch on the 1_8 branch for me? [01:12:22] I'm not at work, so don't have my checkouts [01:12:23] pkasting: yeah [01:12:35] timeless: bug 348779, has a+ already [01:12:37] you know you don't need a full checkout to do landings :) [01:12:39] i never do [01:12:48] I don't have _CVS_ here at home :) [01:12:51] Seg Fault, gdb exit [01:13:05] ginn: upgrade to dbx [01:13:11] timeless: when you check in, mark fixed1.8.1, but leave open, I need to worry about the trunk tomorrow [01:13:19] and thanks! [01:13:51] iunknown: good idea, thanks [01:13:58] timeless: did you mean |call DumpJSStack()| or |DumpJSStack()|? [01:14:15] modules/libreg/include/NSReg.h [01:14:18] (gdb) help call [01:14:19] Call a function in the program. [01:14:24] i'm pretty sure i meant call [01:14:33] ie the former [01:14:46] just as i meant |frame 3| and not |3| :) [01:15:48] timeless: it was more of a question than it was a challenge. ;) [01:16:03] pkasting: what's ui review [01:16:09] and how does it appear in cvs commits? [01:16:12] and how do i spell joe? [01:16:18] ui-r [01:16:20] Mnyromyr [MnyroWork@B9DD71DB.895A7D73.450559D8.IP] has joined #developers [01:16:22] jhughes [01:16:33] gavin: and is this tree open? :) [01:16:42] firebot: trees 8$ [01:16:44] Sunbird-Mozilla1.8 : all 3 tinderboxen green! [01:16:46] Mozilla1.8 : all 11 tinderboxen green! [01:16:51] yes! [01:16:57] <@bz> ginn: is that the whole stack? [01:16:58] bonsai! [01:18:21] bz: no, I think >20 are not related to this issue [01:18:45] philor_ [ringnalda@moz-DE5A9240.eug.or.uspops.net] has joined #developers [01:18:51] <@bz> mmmm [01:19:00] <@bz> they might be [01:19:02] <@bz> depending on what's in them [01:19:05] <@bz> So here's what I think is odd [01:19:15] <@bz> # [01:19:15] <@bz> # [01:19:15] <@bz> #12 0xb70a4169 in nsXPCWrappedJS::CallMethod (this=0x8cddca8, methodIndex=14, [01:19:15] <@bz> # [01:19:15] <@bz> info=0x82f8908, params=0xbfbfb0c0) at xpcwrappedjs.cpp:477 [01:19:15] <@bz> # [01:19:15] <@bz> #13 0xb7e23673 in PrepareAndDispatch (methodIndex=14, self=0x8cddca8, [01:19:15] <@bz> # [01:19:16] <@bz> args=0xbfbfb184) at xptcstubs_gcc_x86_unix.cpp:100 [01:19:17] <@bz> # [01:19:18] <@bz> #14 0xb2500466 in nsAccessibilityService::GetShellFromNode (aNode=0x8cddca8, [01:19:19] philor [ringnalda@moz-20239781.eug.or.uspops.net] has quit IRC: Ping timeout [01:19:20] <@bz> # [01:19:21] <@bz> aWeakShell=0xbfbfb328) at nsAccessibilityService.cpp:294 [01:19:21] <@bz> Why is that happening? [01:19:49] <@bz> 294 aNode->GetOwnerDocument(getter_AddRefs(domDoc)); [01:19:51] node is probably a js object [01:19:54] gavin kicks mozilla clipboard code and pastebin for bz [01:19:55] <@bz> it can't be [01:20:04] is it nsIContent? [01:20:09] <@bz> nsAccessibilityService::GetShellFromNode is called from [01:20:16] <@bz> # [01:20:16] <@bz> #15 0xb250095e in nsAccessibilityService::GetAccessibleByType (this=0x8217d78, [01:20:19] <@bz> Which does [01:20:26] aNode is nSXPCWrapped [01:20:44] <@bz> oh [01:20:45] <@bz> wait [01:20:54] <@bz> it does that elsewhere [01:20:56] <@bz> ginn: why? [01:20:57] gavin: can youkick paste/pastbin for me too? [01:21:17] timeless: sorry, missed your questions. Answers: [01:21:27] <@bz> ginn: how'd that happen? [01:21:34] timeless: I usually write "ui-r" for ui-review [01:21:37] pkasting: it's in cvs, you'll have to tolerate gavin's answers [01:21:45] <@bz> ginn: in any case, if it is that means someone called this code from JS. Who's the someone? [01:21:45] Oh [01:22:13] OK, thanks [01:22:19] I guess I'll mark the bug [01:22:33] NeilZZZ [neil@805FBB74.43DBE11A.6FB37ABF.IP] has quit IRC: Ping timeout [01:22:33] ok [01:22:50] i was about to but i need to wait for bonsai and am trying to arrange a hotel in budapest and help ginn [01:23:52] dan___ [daniel@moz-A0DFFABC.jetstream.xtra.co.nz] has quit IRC: Connection reset by peer [01:24:04] dt [darktemple@moz-B46E4156.adl0.adsl.esc.net.au] has quit IRC: Quit: [01:24:10] graydon [graydon@moz-4322C8E6.vc.shawcable.net] has quit IRC: Ping timeout [01:24:17] http://lxr.mozilla.org/seamonkey/source/accessible/src/xul/nsXULSelectAccessible.cpp#182 [01:24:27] ginn: i hate to ask, but are you on a branch? [01:24:29] <@bz> Right [01:24:37] dt [darktemple@moz-B46E4156.adl0.adsl.esc.net.au] has joined #developers [01:24:38] <@bz> But why is that returning an XPCWrappedJS? [01:24:47] <@bz> It should be returning the underlying C++ object.... [01:24:48] timeless: no, HEAD [01:24:49] <@bz> In any case. [01:24:54] <@bz> What does the rest of the stack look like? [01:25:27] <@bz> huh [01:25:36] <@bz> is this XUL select content or chrome? [01:25:53] bz: xbl probably implements nsCOMPtr [01:26:22] /toolkit/content/widgets/menu.xml, [01:26:23] * line 17 -- [01:26:25] bz: http://pastebin.mozilla.org/455 [01:26:37] <@bz> timeless: right [01:26:38] * [01:26:39] /toolkit/content/widgets/text.xml, [01:26:39] * line 10 -- [01:26:40] Neil_ [neil@moz-228E8524.lutn.cable.ntl.com] has joined #developers [01:26:56] bz: so i don't see any reason this *wouldn't* be a wrapped js [01:27:09] bz: note that accessible tries to wrap xbl things into content [01:27:16] and they usually die becuase of security exceptions [01:27:25] <@bz> ginn: er... what's that the stack to? [01:27:27] Xanthor|aw [Xanthor@1A1B525D.C32EEA8.93BE0828.IP] has joined #developers [01:27:29] presumably precisely matching the ones we see in this stack [01:27:36] <@bz> timeless: hmm... ok, good point. [01:27:39] bz: that's the rest stack [01:27:54] <@bz> ginn: um... so impl_getSelectedChild calls atk_selection_ref_selection ? [01:27:56] could someone remind me why ginn is looking at this stack? [01:28:06] :) [01:28:18] <@bz> because caps is screwing him over [01:28:25] impl_getSelectedChild is in atk-spi [01:28:30] Neil_ [neil@moz-228E8524.lutn.cable.ntl.com] is now known as NeilZZZ [01:29:07] atk_selection_ref_selection is in atk [01:29:45] <@bz> ok [01:30:07] <@bz> ginn: you could breakpoint in nsScriptSecurityManager::GetPropertyAccessImpl and see what subject principal it ends up with [01:30:09] <@bz> and why.... [01:30:44] bz has got to sleep [01:30:44] <@bz> g'night, all [01:30:52] <@bz> ginn: catch me tomorrow if you don't get somewhere by then? [01:30:56] Wevah [Wevah@moz-1BCA74A2.cloudnet.com] is now known as Wevah[z] [01:31:56] bz: thanks [01:32:44] bz [bzbarsky@moz-582D6B46.dsl.chcgil.ameritech.net] is now known as bz_sleep [01:36:29] ss [ss@moz-21C11B32.usma1.compute.amazonaws.com] is now known as ss|Zzz [01:40:13] which field should I look at for subjectPrincipal? [01:46:36] i think that function calculates it or something [01:46:49] so you should be able to read the code and either step through it, or set breakpoints based on where it should know it [01:47:07] it's been a while since i had to look at that code and i'm trying to do some other stuff [01:50:25] sheppy [sheppy@moz-EEBE1278.dhcp.kgpt.tn.charter.com] has quit IRC: Quit: Quitting! [01:58:27] roc? [01:59:30] timeless: bug 352620? [01:59:44] you are the reporter, assignee, r, and sr [01:59:44] anyone know the view code? [01:59:46] haha [02:00:05] sayrer: um, i blah ie [02:00:10] You entered a username that did not match any known Bugzilla users, so we have instead left the requestee field blank. [02:00:18] and bugzilla? [02:00:19] oh, you asked the wind [02:01:07] stuart: how about bug 352573 [02:01:22] timeless, we should really get some js bugs instead of chasing analyzer reports [02:01:43] sayrer: this isn't analyzer [02:01:47] oh, how'd you find it? [02:01:50] it's my compiler complaining that our code is broken [02:01:56] it's been complaining for years [02:02:00] what's your compiler? [02:02:03] but i rarely spend time caring [02:02:12] Forte or something [02:02:15] its name changes every couple of months [02:02:20] Sun? [02:02:24] yes [02:02:36] what in the world are they doing up there in finland [02:02:52] or is this just for fun [02:03:04] i'm pissed at debian ubuntu apt [02:03:10] so iu replaced it with a system that isn't broken [02:03:22] which means i get human readable error messages and such [02:03:29] hmm, you are nicer to Solaris than I am [02:03:31] but mostly i'm cursing s [02:03:36] or are you running Nexenta? [02:03:46] nah, opensolaris [02:03:53] i should look at nexenta [02:03:55] sayrer: fyi, those shifting line numbers from expat are a false alarm - actually quite justifiable [02:04:02] technically solarisnevada i suppose [02:04:27] Nexenta Alpha 4 /almost/ worked for me [02:04:34] auswerk [auslandr@moz-FBC4DCCC.sfo1.dsl.speakeasy.net] has joined #developers [02:04:36] solaris versioning makes ms versioning seem tame [02:04:52] or is it the other way around? [02:05:01] but now I run Ubuntu 64 on my Sun box. It just worked for me [02:05:09] sunos2.x/solaris5.x/snv? [02:05:19] timeless sighs [02:05:27] ubuntu is such a mess when it comes to trying to do dev work [02:05:33] no, sun 5.x / solaris 10.x [02:05:42] especially if you're stupid enough to install from a cd [02:06:04] well, it does take quite a lot of apt-getting to make it usable [02:06:13] every install i've seen always manages to have a distro preference that doesn't match the packages you have installed [02:06:26] and the packages you have installed arem't available from the non cd repositories [02:06:48] which means you instntly get package conflicts when you ask for your first missing package [02:07:08] and then, for some reason debian thopught that updating to gmake3.81 would be a good thing for a stable platform [02:07:31] philly_afk [chatzilla@moz-F39E10DC.cpe.net.cable.rogers.com] has quit IRC: Connection reset by peer [02:07:37] anyway, back to constifying [02:08:24] lint [tim@EBCAB6A5.E9D615ED.6314CA07.IP] has quit IRC: Quit: Leaving [02:12:21] brendan [brendaneic@moz-42090664.hsd1.ca.comcast.net] has quit IRC: Quit: brendan [02:12:53] timeless rotfl [02:13:06] chat * stupid(char * thing) { [02:13:18] if (thing) { return strdup(thing); } [02:13:24] return thing; [02:13:25] } [02:13:28] #define chat char [02:14:38] wow [02:14:52] now, if you decide to make char * thing const char * thing [02:15:10] your code doesn't compile because you're returning a const char* null pointer [02:15:37] I'm looking at a XUL chrome document on a trunk XULRunner, and CDATA sections are being created as text nodes! [02:15:53] is that a problem ;-? [02:15:54] schrep [schrep@moz-7542B0EB.dsl.static.sonic.net] has joined #developers [02:16:39] pamg [pamg@moz-CD91E596.google.com] has quit IRC: Quit: pamg [02:18:06] Hannibal [Hannibal@FF672C8A.2DD6448.BB6EDB21.IP] has joined #developers [02:18:33] sayrer: i think the key is that sparcs like tol use readonly memory pages [02:18:44] so sun's compiler cares [02:19:05] man, I have tried to compile so much shit with that thing and given up [02:19:12] NeilZZZ [neil@moz-228E8524.lutn.cable.ntl.com] has quit IRC: Ping timeout [02:19:22] i've really loved using their compiler [02:19:43] I gather it generates great stuff if you get it to compile [02:19:46] i can't remember if it's hpux or aix which scites chapter and veerse [02:19:50] Neil_ [neil@805FBB74.43DBE11A.6FB37ABF.IP] has joined #developers [02:19:53] i think it's hpux [02:21:12] Neil_ [neil@805FBB74.43DBE11A.6FB37ABF.IP] is now known as NeilZZZ [02:22:46] dveditz [dveditz@moz-452E74B8.cruzio.com] has joined #developers [02:22:46] ChanServ [services@localhost.net] has set mode +o dveditz [02:23:05] hi dveditz [02:23:16] useless bug reviews waiting :) [02:23:34] roc: you still around? [02:24:02] <@dveditz> hi timeless [02:25:29] timeless takes it that roc isn't around [02:25:33] bernd: ping [02:25:40] pong [02:26:00] timeless: well, it's odd behavior, because I'm likely to do some node type checks [02:26:02] is Bug 352523 somethinig you could review? [02:26:19] philor_ [ringnalda@moz-DE5A9240.eug.or.uspops.net] is now known as philor [02:29:14] timeless pokes bernd [02:29:55] timeless: only if you really find nobody else, I am weak at strings [02:30:08] can you do it today? [02:30:13] the goal is to not have things go stale [02:32:50] timeless: no and in general if it does not crash or hangs the browser its below my radar (due to external time constraints) [02:33:12] k [02:33:25] stuart grumbles [02:33:28] this is debug code [02:33:32] iirc [02:33:53] auswerk [auslandr@moz-FBC4DCCC.sfo1.dsl.speakeasy.net] has quit IRC: Quit: Trillian (http://www.ceruleanstudios.com [02:36:12] auswerk [auslandr@moz-FBC4DCCC.sfo1.dsl.speakeasy.net] has joined #developers [02:36:28] orph [nobody@moz-FEE9422B.dsl.pltn13.pacbell.net] has joined #developers [02:38:43] Bernd [bmlk@moz-BF0F2F9F.dip0.t-ipconnect.de] has quit IRC: Quit: Chatzilla 0.9.73 [Firefox 1.6a1/2006011105] [02:40:38] Pike [Axel_Hecht@1F89B737.8FA7E213.64A8B3F8.IP] has joined #developers [02:40:50] beaufour [beaufour@183BDF58.599B7C47.C7DB8B78.IP] has joined #developers [02:40:54] timeless grumbles [02:41:06] nss hackers aren't very careful [02:52:56] timeless sighs [02:53:00] laurentj [laurentj@2D8FB7E9.FB8B17DB.34E6C24D.IP] has joined #developers [02:53:21] timeless wonders what nsCRT::IsAscii(0) does [02:54:32] timeless wonders what nsCRT::IsAscii((const char*)0) does [02:55:25] timeless, why do we allow nsCRT:: at all anymore? [02:56:31] because most people aren't insane enought o volunteer to read mailnews code [02:56:34] let alone touch it [02:56:37] or change it [02:57:02] timeless sighs [02:57:08] new char[10] [02:57:09] or [02:57:12] timeless, but we have nsCRTGlue.h now [02:57:16] PR_Free(new char[10]) [02:57:19] pkasting_home [pkasting@moz-573A738D.dsl.snfc21.sbcglobal.net] has quit IRC: Quit: Leaving [02:57:30] sayrer: do you really want blame for this code? [02:57:50] I will create a hotmail account and review my own code! [02:58:22] (not really) [02:58:30] most of my mailboxes that people would try to mail won't reach me [02:59:02] anyway, lunch [02:59:05] i'll post a patch for mailnews shortly [02:59:07] we could try to delete nsCRT.h [02:59:16] and then you can think about trying to remove it [02:59:16] Pike_ [chatzilla@moz-DB195AC2.dip0.t-ipconnect.de] has joined #developers [02:59:22] that would be ambitious [03:02:39] Pike_ [chatzilla@moz-DB195AC2.dip0.t-ipconnect.de] has quit IRC: Input/output error [03:06:54] gaoming [chatzilla@41233EAD.BD1919A0.787F53A6.IP] has quit IRC: Quit: Chatzilla 0.9.75 [Firefox 1.5.0.6/2006072814] [03:06:57] Pike [Axel_Hecht@1F89B737.8FA7E213.64A8B3F8.IP] has quit IRC: Quit: real life [03:09:29] hwaara [hwaara@CF8C368A.2191EBAD.7EF74A51.IP] has joined #developers [03:10:15] gaoming [chatzilla@41233EAD.BD1919A0.787F53A6.IP] has joined #developers [03:10:34] gaoming [chatzilla@41233EAD.BD1919A0.787F53A6.IP] has quit IRC: Connection reset by peer [03:18:07] Unarmed [unarmed@moz-5EEB135.client.mchsi.com] has joined #developers [03:19:56] Unpresent [unarmed@moz-5EEB135.client.mchsi.com] has quit IRC: Ping timeout [03:26:47] A`ja [chatzilla@moz-F494988D.dsl.stlsmo.sbcglobal.net] has quit IRC: Quit: Chatzilla 0.9.73-rdmsoft [XULRunner 1.9a1/2006042715] [03:33:08] WeirdAl [chatzilla@moz-538880CE.hsd1.ca.comcast.net] has quit IRC: Quit: Chatzilla 0.9.67+ [SeaMonkey 1.0.4/2006072904] [03:33:57] dveditz [dveditz@moz-452E74B8.cruzio.com] has quit IRC: Ping timeout [03:34:51] if I have a webpage with an endless JS loop which creates an alert - how do kill that? I can't close the browser window, because the alert is modal... [03:34:58] sayrer [chatzilla@moz-D9DB9F78.cable.mindspring.com] has quit IRC: Ping timeout [03:35:21] I could shoot the whole app, but that isn't actually what I want to do... [03:35:33] Ryan [rflint@moz-23FBB0CF.res.east.verizon.net] is now known as Ryan|zzz [03:43:03] hm, if I'm lucky, I have a second window where I can turn off JS, but what if I don't? [03:43:20] this looks like possible DOS attack... [03:45:31] Mnyromyr: as far as I know, that's always been possible in just about any browser? [03:45:41] dunno [03:45:58] I was just right now annoyed by it ;-) [03:46:18] looks like bug 61098 or bug 300054 [03:46:45] luckily I _had_ a second window ;-) [03:50:34] A`ja [chatzilla@moz-F494988D.dsl.stlsmo.sbcglobal.net] has joined #developers [03:51:17] mnyromyr venkman is your friend [03:51:43] as long as your browser responds such that you can ask it ot open a new window or venkman from a commandline (or venkman from the new window) [03:51:50] you can stop the thing [03:51:57] timeless: _my_ of course, but I doubt it's my e.g. mother's ;-) [03:52:16] otherwise, i think if you don't have venkman, the enable js pref might be live apply [03:52:39] so it might be sufficient to force a second window (double click firefox shortcut), open prefs and disable js, and then dismiss the dialog [03:54:04] Ryan|zzz [rflint@moz-23FBB0CF.res.east.verizon.net] has quit IRC: Connection reset by peer [03:55:48] timeless frowns [03:55:48] actually I doubt that I can configure SM's script pref in a FF window ;-) [03:55:54] sayrer: want something fun to do? [03:56:08] try to figure out what the memory sotry is for nsMsgSend.cpp [03:56:22] and I configured SM to open a second window, but in the default installation on Windows, it might work [03:56:37] s/window/instance [03:57:45] yeah, the instance thing is a problem [03:58:10] tha's why you always to to keepjsconsole or domi open as a window of last resort if you do disable moz_remote [03:59:20] oh man [03:59:25] i want to kill someone [03:59:44] /mozilla/mailnews/compose/public/nsIMsgSend.idl [03:59:51] %{ C++ [03:59:54] .. [03:59:58] // Attachment file/URL structures [03:59:59] struct nsMsgAttachmentData [03:59:59] { [04:02:26] Pike [Axel_Hecht@moz-DB195AC2.dip0.t-ipconnect.de] has joined #developers [04:03:10] anyone have an idea what would cause some code to not be used/called the first time you launch firefox after a rebuild? if I restart firefox after that, it's always used. [04:03:27] is there a good way to add a javascript: bookmarklet to wiki.m.o? [04:03:41] probably not :) [04:04:37] [javascript:foo() Bookmark me] ? [04:04:44] Hannibal doesn't know whether that'd actually work [04:05:02] I think it's ok with html to some extent, you could try that as well [04:05:02] doesn't seem to like javascript: to begin with, it seems [04:05:06] heh [04:05:08] fun :) [04:05:42] ideas, anyone? [04:05:45] I'm totally clueless... :/ [04:06:31] it's like a quantum bug. if I launch firefox in debug mode, my code always runs. if I just "casually" launch it after a rebuild, it won't run. [04:06:38] hwaara: where is that code? I think that'd probably explain it... maybe. [04:06:57] Hannibal: it's my a11y code, starting in widget/src/cocoa [04:06:58] actually, are you sure it doesn't restart once on first start? [04:07:18] Hannibal is not sure how you're checking whether your code runs [04:07:23] yes [04:07:35] Hannibal: when I attach a debugger, and set a breakpoint, it's not hit [04:07:46] actually, the breakpoint can't even be found then, for some reason [04:07:57] timeless sighs [04:07:58] Hannibal thinks that some reason is probably a clue ;) [04:08:06] this code is so very broken [04:08:06] though I wouldn't be able to tell you why or how. :( [04:08:17] timeless: on average, how many times a day do you say that? :D [04:08:31] I wish I could see at runtime what stuff is "in use" [04:08:46] I mean, more exactly than which shared libs are loaded [04:09:19] can this have to do with the XUL cache or fastload somehow? [04:09:28] hannibal: depends on what kind of code i look at [04:09:37] today i'm examining some maile code [04:09:52] hwaara: it could, theoretically, but that'd be a bug. [04:09:59] I think, anyway. [04:10:05] timeless: heh [04:10:06] Hannibal: how does those things work? what's teh general principle? [04:10:07] hwaara: it could easily relate to how your component registers itself [04:10:17] hwaara: I don't know. I don't like fastload :) [04:10:20] timeless: hmm [04:10:21] mcsmurf [chatzilla@7DE28687.6473F8A6.C8318C80.IP] has joined #developers [04:10:46] timeless: it's loaded the first time it's needed, which is only if you open some third-party app while firefox is running [04:11:10] SeaMonkey: 'Linux lhasa Depend release (gtk2+xft)' has changed state from Success to Test Failed. [04:11:17] mcsmurf: hi [04:11:17] hwaara: https://bugzilla.mozilla.org/show_bug.cgi?id=288410 ;) [04:11:27] hi [04:11:58] oh, I saw that demux assertion yesterday I thik [04:12:10] mmc [mmc@moz-C81D45CC.maths.ed.ac.uk] has joined #developers [04:12:10] mcsmurf: I'm trying to reproduce bug 352520 [04:12:10] hwaara looks in his console [04:12:28] smontagu, I wish I could reproduce it :-/ [04:12:41] looking at bonsai also did not enlighten me very much [04:13:27] hwaara: hrm, that's interesting. I haven't looked into that bug in a very long time [04:13:30] mcsmurf: it seems to me that a crash could happen if GetFocusNode returned null at http://lxr.mozilla.org/seamonkey/source/editor/libeditor/base/nsEditor.cpp#4618 [04:13:34] and the pc I reproduced it on is semi-retired [04:13:49] gandalf [e-gand@4FFBF40E.8157CCE2.AB2CA809.IP] has joined #developers [04:13:55] Hannibal thinks this machine is so many times faster it might no longer be a problem [04:14:07] which could happen according to the comment at http://lxr.mozilla.org/seamonkey/source/layout/generic/nsSelection.cpp#4043 [04:14:13] Hannibal: I will keep an eye open, although I'm skeptical that would be the cause [04:14:17] the question is, when could it happen? :) [04:14:44] hwaara: mm. [04:14:46] someone changed the selection code around that time? [04:15:06] mcsmurf: bug 300131 did [04:15:31] hm... [04:16:48] I tried all kind of deleting text from the url bar now [04:16:52] Neil_ [neil@moz-228E8524.lutn.cable.ntl.com] has joined #developers [04:16:53] and I cannot reproduce [04:17:00] but yesterday the crash happened two times [04:17:38] NeilZZZ [neil@805FBB74.43DBE11A.6FB37ABF.IP] has quit IRC: Ping timeout [04:18:08] Neil_ [neil@moz-228E8524.lutn.cable.ntl.com] is now known as NeilZZZ [04:18:45] whimboo [Miranda@39B4F589.484D324C.349377F5.IP] has joined #developers [04:20:07] mcsmurf [chatzilla@7DE28687.6473F8A6.C8318C80.IP] has quit IRC: Ping timeout [04:20:16] gavin: any changes to your timeline that you are able to check in the patch on bug 57802? Or should I ask another one? [04:21:08] mcsmurf [chatzilla@moz-420733AB.dip.t-dialin.net] has joined #developers [04:21:19] smontagu: sorry, just as we spoke I crashed ;) [04:21:30] and sometimes the debugger locks the whole system [04:21:51] anyway, I have the crash in a debugger now [04:21:57] if you need any var info [04:22:17] you are in nsEditor::DeleteSelectionImpl? [04:22:26] yes [04:22:39] what is deleteNode? [04:22:55] null nsComptr [04:23:27] /* This piece of junk is so that I can use BBDB with Mozilla. [04:23:32] timeless chuckles [04:23:47] that confirms my theories so far :) [04:24:10] mcsmurf: deleteCharOffset is -2? [04:24:19] -1 [04:25:14] humph [04:25:46] deleteCharData and deleteCharOffset? [04:25:59] er, just deleteCharData [04:26:10] null nsCOMPtr [04:27:46] mcsmurf: do you remember what you did? [04:28:02] I think I pressed the backspace key at the end of the URL [04:28:19] no selection present afaik [04:28:29] how did the URL get into the URL bar? [04:28:47] hm... [04:29:00] I think I clicked a link on a webpage [04:29:53] ah, -1 doesn't demolish my theory after all [04:29:58] heh :) [04:30:02] Unpresent [unarmed@moz-5EEB135.client.mchsi.com] has joined #developers [04:31:24] smaugZzz [chatzilla@moz-DDD2A5AD.pp.htv.fi] has quit IRC: Quit: Chatzilla 0.9.75 [Firefox 3.0a1/0000000000] [04:31:31] Unarmed [unarmed@moz-5EEB135.client.mchsi.com] has quit IRC: Ping timeout [04:32:13] smaug [chatzilla@93F5D356.851FF927.9BAB7257.IP] has joined #developers [04:32:55] Hannibal [Hannibal@FF672C8A.2DD6448.BB6EDB21.IP] has quit IRC: Quit: Chatzilla 0.9.75-rdmsoft [XULRunner 1.8.0.4/2006060814] [04:34:08] zwnj|away [zwnj@A27B03AD.DA3750AA.22199703.IP] has quit IRC: Quit: ZWNJ.org [04:34:47] zwnj [zwnj@A27B03AD.DA3750AA.22199703.IP] has joined #developers [04:37:08] mcsmurf: I suppose parentNode is out of scope [04:37:20] wolfiR [stark@D8346595.E0FEA68B.F7F6D21D.IP] has joined #developers [04:37:27] it says null nsCOMPtr for it [04:37:41] don't know if this is realistic [04:38:06] what about aAction? [04:38:15] if everything is null, something strange is going on ;-) [04:38:17] aAction is 0 [04:38:20] heh ;) [04:38:29] and you are at line 4630 like in the stack trace? [04:38:32] Unarmed [unarmed@moz-5EEB135.client.mchsi.com] has joined #developers [04:38:37] Hannibal [Hannibal@moz-35450EE3.lijbrandt.net] has joined #developers [04:38:39] yes... [04:38:52] that makes no sense whatever, something is corrupted [04:39:02] note that this build has opt enabled [04:39:12] but so far this has only tricked me once [04:39:23] (in NSPR, there the var data was totally wrong) [04:39:30] and NSPR used O2, not O [04:39:49] Unpresent [unarmed@moz-5EEB135.client.mchsi.com] has quit IRC: Ping timeout [04:40:01] Hannibal [Hannibal@moz-35450EE3.lijbrandt.net] is now known as Hannibal-afk [04:40:22] mcsmurf: selection is null also? [04:40:37] no! :) [04:41:12] (did I select something?!) [04:42:28] what about selection->anchorNode? [04:42:48] um... [04:42:50] mAnchorNode, rather [04:42:57] ok [04:43:02] remote debugging is such fun [04:44:05] ManoZZZ [chatzilla@moz-73245C75.cable.012.net.il] is now known as Mano [04:45:22] you could always do remote debugging :o [04:45:55] smontagu: if you have windows, mcsmurf can give you a dmp and let you really debug locally [04:46:06] and if my debugger would not hate me, I could actually tell you about mAnchorNode [04:46:20] I cannot figure out how to get WinDBG to display me this :/ [04:46:51] mcsmurf: locals? [04:47:14] A`ja [chatzilla@moz-F494988D.dsl.stlsmo.sbcglobal.net] has quit IRC: Quit: Chatzilla 0.9.73-rdmsoft [XULRunner 1.9a1/2006042715] [04:47:16] I don't see mAnchorNode anywhere as child of selection [04:47:35] (or better said as child of __vtcast_nsTypedSelection) [04:48:02] smontagu: is it? [04:48:26] mcsmurf: dt/dv w/ recursion can also work, if you want to [04:48:55] eww [04:48:58] timeless kicks mime [04:49:23] it really does randomly corrupt its input [04:50:28] mcsmurf: mAnchor... anything? [04:50:37] mAnchorFocusRange [04:50:53] null? [04:51:05] no [04:51:50] mStartParent and mEndParent are both some nsHTMLDivElement [04:52:11] (different elements, that is) [04:52:11] jwatt [roslea@jwatt.irc.users.mozilla.org] has joined #developers [04:52:28] actually. [04:52:29] no [04:52:50] the mRawPtr is the same for both [04:53:37] mStartOffset is 1 and mEndOffset is 1 [04:54:01] while(index < length) { [04:54:01] line[index] = line[index + 1]; [04:54:05] index++; [04:54:06] } [04:54:10] yum :) [04:56:08] orph [nobody@moz-FEE9422B.dsl.pltn13.pacbell.net] has quit IRC: Ping timeout [04:57:56] anyone know if there's a way to find out which element has focus? [04:58:11] timeless: wow, sloth doesn't use threading :/ updating the info beachballs the app [04:58:34] jwatt: XUL? [04:58:42] hwaara: yeah [04:58:56] iirc, there's something like hasFocus(), or maybe you just fetch the "focus" attr [04:59:00] well, XUL with embedded SVG [04:59:02] there is a way, try LXRing [04:59:12] hasFocus seems to be IE only [04:59:18] focus is a function to set the focus [04:59:21] we're doing stuff like that in our bindings [04:59:29] let me look [04:59:39] it's something like window.focusDispatcher or something similarly strnage [04:59:39] hmm, so it is possible, good good :) [04:59:41] thanks :) [04:59:42] Unpresent [unarmed@moz-5EEB135.client.mchsi.com] has joined #developers [04:59:55] weird [05:00:27] timeless: how much bandwidth does remote debugging actually need? [05:00:29] few or much? [05:00:39] (few=up to 10KB/s) [05:00:46]