Irakli Gozalishvili [:irakli] [:gozala] [@gozala] Reporter
	Description • 10 years ago

Right now registered tools don't get any opportunity to participate in iframe creation that is used to load tool document. This is little limiting for stuff that devtools SDK is trying to do & looks like it's a major issue for firebug.next.

I propose to extend `gDevTools.registerTool` API so that tools could opt-in into creating their own iframe. I propose to add optional `createView(document) -> HTMLIFrameElement` method to a tool definition which if provided will be invoked with a `document` and returned iframe will be used, if omitted iframe will be created for a tool as it is now. This will enable tools create an iframe they wish to have.

Another request coming from Honza was to let tool decide where that iframe is going to be injected. I am personally not sure about reasons so I'd rather let Honza elaborate on why & how does he see it fit.
If I had to propose something here I'd say let's extend API as proposed above and check if `iframe` has `ownerDocument` if so leave it alone, otherwise inject it into `vbox` as it's done now.

	Irakli Gozalishvili [:irakli] [:gozala] [@gozala] Reporter
	Comment 1 • 10 years ago

Need info people I was suggested to discuss this with on IRC. As a side note, I'm happy to work on the proposed patch or let anyone do it instead ;)

	Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]
	Comment 2 • 10 years ago

I don't see any reason a tool shouldn't be able to create it's own iframe.

Feel free to implement this if you would like.

	Joe Walker [:jwalker]
	Comment 3 • 10 years ago

I'm not against this, but I'm unclear of the reasons.

	Paul Rouget [:paul]
	Comment 4 • 10 years ago

(In reply to Irakli Gozalishvili [:irakli] [:gozala] [@gozala] from comment #0)
> Right now registered tools don't get any opportunity to participate in
> iframe creation that is used to load tool document. This is little limiting
> for stuff that devtools SDK is trying to do & looks like it's a major issue
> for firebug.next.

Can we get some more details about these limitations?

	Jan Honza Odvarko [:Honza] (always need-info? me)
	Comment 5 • 10 years ago

The main problem I have been facing with the current API is related to the fact that extensions don't have direct access to the <iframe> element just after it's created.

Having the ability to access the element (e.g. reference passed to a callback) would allow extensions to change location of the element within the (XUL) DOM (useful in cases where extensions want to change layout of the panel content).

See also my original bug 980410 comment #7

Having something like suggested `createView(document)` would solve this problem since extensions can provide custom parent element (as well as specify custom attributes for the <iframe> and immediately register listeners).

Honza

	Jan Honza Odvarko [:Honza] (always need-info? me)
	Comment 6 • 10 years ago

@Irakli: can we merge this into the devtools branch?

Honza

	Irakli Gozalishvili [:irakli] [:gozala] [@gozala] Reporter
	Comment 7 • 10 years ago

(In reply to Jan Honza Odvarko [:Honza] from comment #6)
> @Irakli: can we merge this into the devtools branch?
> 
> Honza

Merge what ? Are you referring to devtools branch on SDK ? If so, there is nothing we can do on SDK side if the gDevTools.registerTool API won't be modified as suggested above.

	Jan Honza Odvarko [:Honza] (always need-info? me)
	Comment 8 • 10 years ago

(In reply to Irakli Gozalishvili [:irakli] [:gozala] [@gozala] from comment #7)
> Merge what ?
https://github.com/mozilla/addon-sdk/pull/1571

> Are you referring to devtools branch on SDK ?
Yes

But perhaps it should be done as part of Bug 980410 - Toolbox panel API (edit) ?

Honza