Known Networks 		ChatZilla error 	Connected Networks 	<none>
URL 	irc://foo/bar 	Not Connected 	Lag 	<unknown>
URL 	irc://whereswaldo.mit.edu:57000/developers,needpass 	Mode 	+ns 	Users 	71, 4@, 0%, 0+
Topic 	<dbaron> (ANAL) * smontagu resists the obvious joke || #bugday in progress
URL 	irc://foo/bar 	Connected via 	<none>
<none>
<none>
URL 	irc://foo/bar 	Connected to 	<none>
<none>
File 		Progress 	<unknown>
 
#developers
	[INFO]	Messages Cleared.
	mrbkap	bz: http://lxr.mozilla.org/seamonkey/source/parser/htmlparser/src/CNavDTD.cpp#790 doesn't make much sense to me
	CTho|studying	timelyx: but i'll keep that in mind, thanks :)
	mrbkap	bz: Why can't we just test for <script>?
	bz	mrbkap: what do you mean?
	mrbkap	bz: eHTMLTag_table contains kNone
	bz	ok
	Which means what, in this case?
	slowly recalls what's going on here
	mrbkap	bz: I'm trying to think of a solution to bug 288186
	bz: Which may involve rethinking when/where we handle misplaced content
	bz	Ah
	-->|	kerz (kerz@moz-F696F1E8.dsl.pltn13.pacbell.net) has joined #developers
	bz	So the script closes out the <select>
	mrbkap	bz: Not quite :)
	timelyx	sighs
	needs to attack libjar
	mrbkap	bz: When we handle misplaced content, we close all new open containers. So by the time we handle the misplaced <option>, the <select> has been opened and closed.
	timelyx	iirc it opens things for exclusive access or something
	mrbkap	bz: (which is the reason for bug 286733)
	bz	wait
	in this case, the <select> is misplaced
	right?
	mrbkap	Right
	|<--	swalker has left whereswaldo.mit.edu:57000 (Quit: swalker)
	bz	So we ship out everything from its opening tag to the closest thing that's a valid child of <table>
	Which is <script>
	mrbkap	Right
	bz	Then we (separately) ship out the <option>
	Which then can't be opened at all, so just gets dropped
	Right?
	mrbkap	Right.
	bz	should have attached a testcase to bug 243064
	'cause I can't recall what that page looked like. :9
	:(
	mrbkap	bz: So I don't think we should try handling misplaced content until we've seen a <tr> (or <td>, I guess judging by the comments in the code)
	bz	mrbkap: hmmm... possibly...
	mrbkap	bz: So in this case, we'd put the <select> in the misplaced content queue, handle the <script> normally, then continue collecting misplaced content.
	bz	Hmm
	|<--	d3a693a0-97e3-11d9-9669-080020 has left whereswaldo.mit.edu:57000 (Quit: Chatzilla 0.9.67 [Firefox 1.0+/20050324])
	bz	Oh, I see
	So right now we process misplaced content when we hit the <script>
	right?
	There's one little problem here....
	If a script runs, we need to have the DOM be up to date, no?
	mrbkap	hm
	bz	Since it can rearrange things...
	I know we certainly flush out everything we can in the sink...
	mrbkap	I wonder if the <select> appers in IE's DOM
	sighs
	Yeah, it has to be visible.
	wonders if we can keep the <select> context around even after it's been closed.
	mconnor	ok, I have to ask, was our parser really that bad before? how many kludgy workarounds are we breaking by all of this imposition of sanity?
	bz	mconnor: That is a _very_ good question.
	mrbkap	Hopefully none :/
	bz	mconnor: And the answer is, "hopefully fewer than we're adding"
	mconnor	bz: haha, niice, I can live with that ;)
	bz	mconnor: But yes, messing with the parser is generally dangerous....
	mrbkap	How's this for dangerous:
	When handling misplaced content, we make a temporary context at http://lxr.mozilla.org/seamonkey/source/parser/htmlparser/src/CNavDTD.cpp#1953
	How about keeping that around until we see a <tr> or <td>?
	Actually, shoot.
	We use the body :(
	|<--	dria has left whereswaldo.mit.edu:57000 (Quit: Leaving)
	-->|	benaway (ben@adsl-69-107-32-56.dsl.pltn13.pacbell.net) has joined #developers
	mconnor	bz: well... when 1.1 ships, we'll find out I suppose :)
	Waldo	mconnor: thanks for reviewing my patch in bug 279227 so quickly - when did you suddenly get so much more time? :-)
	CTho|studying	bz: re: bug 287695 - what you say sounds good. i haven't heard of that before, but i'll look at it tomorrow
	mconnor	Waldo: I didn't. I was just procrastinating on work stuff, and since xchat pings me.. I usually look, and if its simple/sane I'll dig in
	Waldo	mconnor: mm, I see
	's hopes die ever-so-slightly
	mconnor	Waldo: in another few weeks, I'll have a lot more time for this stuff
	Waldo	mconnor: sounds good
	|<--	sp3kzZZz has left whereswaldo.mit.edu:57000 (Quit: z)
	Waldo	mconnor: by the way, what do I need to do to get permission to make checkins in browser/toolkit outside of the Help modules?
	mconnor	goes back to turning his buglist into something slightly resembling an actual list of achievable tasks
	Waldo: oh, hrm
	timelyx	mconnor: good luck
	Waldo	(somewhere in my original cvs account bug I got limited to Help - trying to find bug# now)
	mconnor	Waldo: if I read the rules right, getting access to a module governed by review (no SR) only needs a voucher who's an owner/peer for that module, so... I don't know if there's some official blessing to bestow or something
	Waldo	Mano mentioned once that your approval was enough, tho I don't know where he got that info
	mconnor	Waldo: but I won't blink if you land stuff in browser/toolkit with proper review
	dbaron	bz: what's the bug on "BindToTree"?
	mconnor	Waldo: http://www.mozilla.org/hacking/getting-cvs-write-access.html
	mrbkap	bz: I can't figure out how to fix this bug without resorting to dynamic insertion by the parser, which simply won't happen, I think...
	bz	dbaron: 286000
	dbaron: why?
	dbaron	wants to understand what it is before proposing other things
	bz	dbaron: heh
	dbaron: note that I have it pretty much working
	dbaron: But if you have a better idea, I can do that...
	dbaron	wants documents to track content that has them as an ownerDocument but isn't in their tree
	I just wanted to know what you're doing and if it's related.
	=-=	gavin is now known as gavin|away
	dbaron	wants to use the ownership of the ownerDocument :-)
	bz	dbaron: What I'm doing is merging SetDocument/SetParent/SetBindingParent into two functions: BindToTree and UnbindFromTree
	dbaron	yeah, I see that
	vlad	dbaron: oh hey, quick question
	bz	dbaron: btw, with XBL transitivity is great fun
	vlad	dbaron: and "let's discuss it tomorrow in person" is a valid answer
	Waldo	mconnor: problem is that's directed toward "core" hackers, and a core hacker I most certainly am not
	dbaron	bz: transitivity?
	bz	dbaron: er, symmetry
	mconnor	Waldo: there's lots of grey areas in any policy :)
	mrbkap	oo
	bz: I may have a loophole
	bz	dbaron: xbl anon content has a weak ptr to the bound node
	vlad	this <canvas> thing will have nsI*CanvasElement, nsI*CanvasRenderingContext, nsI*CanvasRenderingContext2D related interfaces
	mrbkap	checks more
	bz	dbaron: which has a strong ptr to the binding
	dbaron: which has a strong ptr to the anon content root
	Waldo	mconnor: your comment <https://bugzilla.mozilla.org/show_bug.cgi?id=278979#c1> in Mano's account bug suggests I don't need anything more for browser/toolkit - shall I count that in my favor? ;-)
	bz	dbaron: which holds strong ptrs to the anon content....
	vlad	should those be nsIDOMHTMLCanvasElement and live in dom/public/idl/html ?
	bz	dbaron: if we implemented the sXBL model it'd be cleaner.... :(
	mconnor	<mconnor> Waldo: but I won't blink if you land stuff in browser/toolkit with proper review
	Waldo	whee! good enough for me
	dbaron	vlad: If you want the element one to be scriptable, probably ,but as nsIDOMNS*, and you should talk to jst.
	Waldo	saves a transcript for the record
	dbaron	presumes it has to be scriptable ;-)
	bz	hmm
	vlad	indeed :)
	nsIDOMNS is netscape/moz dom extensions?
	dbaron	yeah
	mconnor	Waldo: direct any complaints to me.