brahmana wonders if biesi was able to examine the UML diagrams
[ 8:24 pm] <biesi> brahmana, sorry not yet
[ 8:24 pm] <brahmana> thought so..
[ 8:24 pm] <brahmana> biesi, anyways another quick question.
[ 8:25 pm] <biesi> brahmana, yes?
[ 8:26 pm] <brahmana> biesi, Can you please have a look at this one: http://wiki.mozilla.org/images/a/a0/Brahmana_URI_Loading_DocShell_Code.jpg -- Which would be the ideal point in the sequence to associate the tabId to the channel created.
[ 8:26 pm] <brahmana> ?
[ 8:26 pm] <brahmana> biesi, I want to know where I will have access to both of them.
[ 8:27 pm] <timeless> brahmana: pretty
[ 8:27 pm] <biesi> brahmana, um
[ 8:28 pm] <biesi> brahmana, nothing in that diagram has access to both :-)
[ 8:28 pm] <brahmana> timeless, thank you.. more here: http://wiki.mozilla.org/User:Brahmana/Netwerk_Docs (just in case)
[ 8:29 pm] <brahmana> biesi, ok.. so how much prior to webBrowser will I have to go to get a tabID ?
[ 8:29 pm] <biesi> brahmana, tabbrowser.xml
[ 8:29 pm] <biesi> its loadURI function or something like that
[ 8:29 pm] <biesi> brahmana, of course some things call loadURI on the web navigation directly...
[ 8:29 pm] <brahmana> biesi, yeah.. thats how I created that sequence diagram..
[ 8:30 pm] <brahmana> biesi, Can't I get hold of the tabID in C++ ?
[ 8:30 pm] <biesi> C++ has no concept of "tab"
[ 8:31 pm] <brahmana> But the <browser> present in each tab corresponds to one nsIWebBrowser, isn't it?
[ 8:31 pm] <brahmana> <browser> == the xul browser element
[ 8:35 pm] <biesi> brahmana, no
[ 8:35 pm] <biesi> there is no nsIWebBrowser in firefox
[ 8:36 pm] <biesi> that's only used for embedding
[ 8:36 pm] <timeless> unfortunately we don't use the same apis everywhere :(
[ 8:37 pm] <brahmana> oh man..
[ 8:37 pm] <biesi> brahmana, there is one docshell per tab
[ 8:37 pm] <brahmana> then the starting of my sequence diagram is wrong..
[ 8:37 pm] <biesi> if that helps you
[ 8:37 pm] <brahmana> yeah.. I am aware of that..
[ 8:38 pm] <brahmana> and I thought it was nsWebBrowser that held a reference to a docShell and made calls on the docShell
[ 8:38 pm] <biesi> ah, no
[ 8:38 pm] <brahmana> But as it appears firefox does not use nsWebBrowser itself...
[ 8:38 pm] <biesi> the browser holds the docshell directly, I believe
[ 8:39 pm] <brahmana> you mean the xul browser ?
[ 8:39 pm] <biesi> yeah
[ 8:39 pm] <brahmana> What C++ object does that map to?
[ 8:39 pm] <brahmana> something under widgets?
[ 8:39 pm] <biesi> the xul browser?
[ 8:39 pm] <brahmana> yeah
[ 8:40 pm] <biesi> um
[ 8:40 pm] <biesi> some xul magic
[ 8:40 pm] <biesi> nsXULElement.cpp perhaps
[ 8:40 pm] <brahmana> oh.. let me see
[ 8:40 pm] <biesi> via the boxObject maybe?
[ 8:41 pm] <biesi> but note that the <browser> is mostly an XBL thingy
[ 8:41 pm] <brahmana> oh man.. this is getting heavily complex..
[ 8:41 pm] <timeless> it really is
[ 8:43 pm] <brahmana> Now the JS call: browser.loadURI() will be a call on the corresponding nsXULElement object, which actually holds a reference to the docShell. Is that right?
[ 8:45 pm] * brahmana requests to put aside the XPCOM stuff that happens in the above sequence..
[ 8:45 pm] <brahmana> sorry, the XPConnect stuff..
[ 8:46 pm] <gavin|> yes
[ 8:46 pm] <gavin|> though the nsXULElement isn't really involved
[ 8:46 pm] <gavin|> apart from being associated with the JS object that implements the XBL methods
[ 8:48 pm] <brahmana> gavin|, Can you please elaborate a little on your last statement..
[ 8:48 pm] <brahmana> ?
[ 8:49 pm] <brahmana> Or is there a doc that I can read up to orient myself a little before asking lots of questions here?
[ 8:49 pm] <gavin|> nsXULElement itself doesn't have anything to do with the XBL implemented methods
[ 8:50 pm] <gavin|> it's just a "container"
[ 8:51 pm] <gavin|> it's not really useful to say that you're interacting with a nsXULElement, because you're really interacting with an XBL bound node
[ 8:51 pm] <gavin|> and the XBL <browser> methods implemented in JS are what matters
[ 8:51 pm] <gavin|> not the nsXULElement class methods
[ 8:52 pm] <brahmana> oh.. ok. so the browser.loadURI() is (most probably) implemented in the JS itself. This JS object holds a reference to the docShell directly and thats how the calls are routed -- makes sense?
[ 8:53 pm] <gavin|> that's about right
[ 8:55 pm] <brahmana> now this XBL/JS implementation is present in tabbrowser.xml?
[ 8:56 pm] <gavin|> and browser.xml, yeah
[ 8:56 pm] <gavin|> the tabbrowser contains <browser>s
[ 8:57 pm] <brahmana> This is the one I should be looking at: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml , right?
[ 8:58 pm] <gavin|> yes
[ 9:04 pm] <brahmana> gavin|, ok.. i figured the exit point to docShell: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml#186 --
[ 9:04 pm] <brahmana> Now I want to get the tabId in which this browser object is, how would I achieve it?
[ 9:04 pm] <gavin|> brahmana: not sure what you mean by "tabId"
[ 9:05 pm] <brahmana> tabIndex, the index of the tab in the tabContainer
[ 9:05 pm] <gavin|> you have a reference to a <browser>, and want to find which tab it's in?
[ 9:06 pm] <brahmana> yes..
[ 9:06 pm] <brahmana> well actually I am inside the browser's definition itself..
[ 9:06 pm] <gavin|> I guess you you need to loop through tabs and compare against their .linkedBrowser
[ 9:06 pm] <gavin|> don't think there's a utility method to do that
[ 9:07 pm] <brahmana> ok.. let me see how I can accomplish that..
[ 9:08 pm] <brahmana> I am thinking this... for(i=0; i < this.parentNode.browsers.length; ++i) if(this.parentNode.browsers[i] == this) return i
[ 9:09 pm] <brahmana> that must work, isn't it?
[ 9:09 pm] <gavin|> probably
[ 9:09 pm] <gavin|> assuming this.parentNode is the tabbrowser
[ 9:09 pm] <brahmana> yeah.. I verified that..
[ 9:09 pm] <gavin|> though the "browsers" getter builds an array by looping through taqbs
[ 9:09 pm] <gavin|> so it would best be avoided
[ 9:09 pm] <gavin|> to avoid having to loop twice
[ 9:10 pm] <brahmana> oh.. instead we directly loop through the tabs..
[ 9:10 pm] <gavin|> yeah
[ 9:10 pm] <gavin|> http://mxr.mozilla.org/seamonkey/source/browser/base/content/tabbrowser.xml#1693
[ 9:11 pm] <brahmana> And if i change the XBL now, is there anything that I need to do during the build?
[ 9:11 pm] <gavin|> you just need to rebuild browser/
[ 9:11 pm] <gavin|> (or toolkit/ if you're touching browser.xml
[ 9:12 pm] <gavin|> why are you changing them, though?
[ 9:12 pm] <brahmana> ok.. thats great.. i can even go for a full build.. :-)
[ 9:12 pm] <brahmana> I want to associate every channel with the tab it is working for..
[ 9:14 pm] <gavin|> brahmana: is therea bug # for this?
[ 9:15 pm] <brahmana> gavin|, oh no.. there isn't.. I saw similar thing in Firebug, Cookie Manager and wanted to explore on that..
[ 9:15 pm] <brahmana> if by any means this is a desirable thing we can have a bug...
[ 9:24 pm] <brahmana> Is the code under xpfe/ still used?
[ 9:25 pm] <gavin|> some of it is
[ 9:25 pm] <brahmana> the window mediator?
[ 9:25 pm] <gavin|> yes
[ 9:26 pm] <brahmana> Along with the tabIndex I would also require some sort of window Id i guess, as tabIndices are not unique across browser windows, isn't it?
[ 9:26 pm] <gavin|> right
[ 9:27 pm] <bz> tabindices need not be unique within a single window either
[ 9:28 pm] <gavin|> er, why wouldn't they be?
[ 9:28 pm] <brahmana> oh.. well if we do not open and close stuff, they should be right?
[ 9:28 pm] <bz> because they're under the control of the page author?
[ 9:28 pm] <bz> And nothing prevents an HTML author from sticking tabindex="2" on every single node in the document
[ 9:28 pm] <gavin|> we're talking browser tabs
[ 9:28 pm] <bz> oh
[ 9:29 pm] <bz> nevermind, then
[ 9:31 pm] <brahmana> gavin|, And about the bug for the stuff I am asking, I assume this isn't really a desired feature, is it?
[ 9:31 pm] <gavin|> brahmana: I still don't really know what the feature is
[ 9:35 pm] <brahmana> gavin|, To observe requests for one tab in observerservice ... there is requirement for coupling tab index with the http channel....
[ 9:35 pm] <brahmana> And that is what I am trying to accomplish, associate the tabIndex with the channel..
[ 9:37 pm] <bz> brahmana: er.... you know the docshell involved in both places, right?
[ 9:39 pm] <brahmana> bz, yeah.. I was talking to gavin and others about the way browser interacts with docShell. But I did not fully understand your question.
[ 9:39 pm] <brahmana> browser as in the xul browser element.
[ 9:40 pm] <bz> brahmana: docshell is he guts of a browser
[ 9:40 pm] <bz> brahmana: the part that actually holds the web page, etc
[ 9:41 pm] <brahmana> bz, yeah.. that was evident from this one: http://www.mozilla.org/projects/embedding/docshell.html and also from the length of nsDocShell.cpp file..
[ 9:43 pm] <bz> ok
[ 9:43 pm] <bz> so you can get from a tab to a docshell
[ 9:43 pm] <bz> you can get from the channel to a docshell (usually)
[ 9:43 pm] <bz> then compare the two
[ 9:43 pm] <bz> for images you're out of luck
[ 9:45 pm] <biesi> brahmana, there can be a <browser> that's not part of a <tabbrowser>
[ 9:46 pm] <brahmana> bz, Whats special about the images?
[ 9:46 pm] <biesi> what's NOT special about images
[ 9:46 pm] <bz> brahmana: they don't so much follow necko rules
[ 9:46 pm] <brahmana> biesi, Are you referring to a situation with single tab?
[ 9:47 pm] <brahmana> bz, biesi yeah I had got the same statement when discussing about the request end notifications..
[ 9:47 pm] <biesi> brahmana, no, I'm referring to extensions or mailnews or whatever that doesn't support tabs
[ 9:47 pm] <brahmana> biesi, oh well.. that is probably not a problem. I don't think we would go beyond firefox.
[ 9:48 pm] <biesi> ok
[ 9:48 pm] <biesi> I have no idea what you're trying to do
[ 9:48 pm] * bz points to "extensions"
[ 9:48 pm] <bz> anyway
[ 9:48 pm] <biesi> I'm just saying, if you want to change browser.xml in mozilla.org
[ 9:48 pm] <biesi> 's repository, you can't assume that there's a tabbrowser
[ 9:49 pm] <brahmana> point fully accepted.. :-)
[ 9:50 pm] <brahmana> bz, I am not sure about getting to a docShell from a channel. Is there is straight forward way?
[ 9:51 pm] <brahmana> s/there is/there a
[ 9:54 pm] <brahmana> moreover the docShell will have reference only to one channel and I assume that is channel corresponding to the base document, i.e the main document request. Is that so?
[ 9:55 pm] <bz> brahmana: the docshell is the channel's loadgroup's notification callbacks
[ 9:55 pm] <bz> brahmana: generally
[ 9:55 pm] <bz> brahmana: we're talking about a channel having a reference to the docshell, not the other way around
[ 9:57 pm] <biesi> the load group has the channels/requests for all the loads
[ 9:57 pm] <biesi> except for iframes of course
[10:00 pm] <brahmana> biesi, bz.. a little out of the current discussion.. When the http-on-modify request is fired, will the connection be already set up? Is there a possibility to change the request URL in that event's listener?
[10:01 pm] <bz> "change" in what sense?
[10:01 pm] <biesi> the connection is not set up yet
[10:01 pm] <biesi> but you can't change the URL
[10:01 pm] * bz really wishes URIs were immutable and that channels' URI were readonly so people wouldn't ask questions like this
[10:01 pm] <biesi> the channel's URI IS readonly
[10:01 pm] <brahmana> ok.. :-)
[10:01 pm] <bz> ah, good
[10:01 pm] <bz> well, that URIs were immutable, then
[10:02 pm] <bz> I thought we were gonna do that for http sometime
[10:02 pm] <bz> flip the bit
[10:02 pm] * brahmana decides not to ask such questions to be compliant with bz's wishes..
[10:02 pm] <bz> (and see what breaks)
[10:02 pm] <biesi> oh we aren't? that sucks :/
[10:02 pm] <bz> well
[10:02 pm] <bz> we're not _yet_
[10:02 pm] <bz> I also wish URIs were immutable by default instead of the nsIMutable mess..
[10:02 pm] <bz> but then again, I could use a pony too
[10:02 pm] <bz> Or better yet, a kayak
[10:02 pm] <bz> it is?
[10:03 pm] * bz looks in his "to check in" folder
[10:03 pm] <biesi> there's so much stuff that I'd like to change if I could...