Closed Bug 340531 Opened 19 years ago Closed 19 years ago

Sunbird should be built with DOM Inspector by default

Categories

(Calendar :: General, defect)

Product:
Calendar
Component:
General
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: sipaq, Unassigned)

References

(
URL
)

Details

Now that DOM Inspector support has finally been checked in for Sunbird we should enable DOMI for all builds by default. IMO it is an invaluable tool for front-end development and since we're still pretty early in the app development phase we should make life for all developers significantly easier. The additional download size is a tradeoff that we should make at least until we get near 1.0. Comments?
How useful is DOMi for non-devs in bug-filing? If the only people that benefit from DOMi are the people likely to be building their own copies anyway, then we shouldn't do this. If, however, it's proven useful for bug-filing or other purposes, then I'd support doing this.
I don't consider DOMI especially useful for bug-filing. But I consider it useful for the following cases: - extension development If you want to build an overlay for an existing dialog or other parts of our UI, you'll need the IDs of different items of this dialog/UI. This is very hard to find out with quite a few parts of our UI. With DOMI it is very easy. In addition DOMI is very widely used in the extension development community. - front-end development Debugging XUL/CSS without DOMI is very painful. Stuff like the patch in bug 189416 would have taken me a lot of less time, had DOMI been available. And I still don't know why the same approach as taken in the patch doesn't work for Lightning. I hope to find out soon with DOMI. Also don't forget that these simple XUL-only or XUL+JS patches are often the gateway into Mozilla development in general and Sunbird development in particular. - Power-users tweaking the UI Power users want to tweak the UI (by using a userchrome.css file for example). This is much easier if you have DOMI at hand.
My preference is to fix/finish the installers so users can check or uncheck the DOMi box. However, Mac users don't have an installer, so they'd need to download it from somewhere else. Perhaps we don't build it by default, but put it on a.m.o for others to download that way?
I vote for wontfixing this. dom inspector is only useful for people that should be able to install it. For every one else (should be the majority of users) it just add to the download size and adds a confusing menu option. So I see no advantage in including this by default. (Same point about confusing options goes for the installer. In fact, that's even worse. You force the user to think about an option they don't understand. Even when it's not checked on by default) This does mean that we need to make sure that sunbird-compatible dom inspector xpi's are available.
(In reply to comment #4) > This does mean that we need to make sure that sunbird-compatible dom inspector > xpi's are available. After talking with shaver, DOMi has binary pieces that have to be in sync with the version of Gecko used by the host app. Given that, I vote for building it in nightlies until we are shipping against a "stable" Gecko release.
The only cpp file i can find for inspector is http://lxr.mozilla.org/seamonkey/source/extensions/inspector/build/src/nsInspectorModule.cpp which can easily be rewritten in javascript. But on the 1.8 branch, there is indeed more binary. I still vote for not enabling domi. 'temporary' fixes tend to be not-so temporary...
(In reply to comment #6) > The only cpp file i can find for inspector is > http://lxr.mozilla.org/seamonkey/source/extensions/inspector/build/src/nsInspectorModule.cpp > which can easily be rewritten in javascript. extensions/inspector/build/src/nsInspectorModule.cpp isn't used anymore on the trunk, since the bindary parts of DOMi have all been moved to layout. See bug 340081 comment 9 (and bug 325100).
sipaq, given comment #7 and mvl's comments, do you still want to fight for this one or can we WONTFIX it?
I'm fine with WONTFIX'ing it, if DOMI XPI's are regularly made available somewhere. Any ideas on how to achive that?
(In reply to comment #9) > I'm fine with WONTFIX'ing it, if DOMI XPI's are regularly made available > somewhere. Any ideas on how to achive that? Given our limited resources, the easiest way I can think of is building DOMi by default until 1.0
All our tinderboxes build Thunderbird+Lightning with "--enable-extensions=default, lightning, inspector, venkman". Shouldn't that result in an inspector.xpi file being build that is compatible with Sunbird? If that file would be automatically uploaded to ftp server there would be always a current DOMi for Sunbird available for download.
(In reply to comment #11) > Shouldn't that result in an inspector.xpi file being build that is compatible > with Sunbird? If that file would be automatically uploaded to ftp server there > would be always a current DOMi for Sunbird available for download. Sounds like a lot more of a pain than simply enabling DOMi until we're closer to 1.0 Ff and Tb have it in the alphas and stuff, and remove it for release.
(In reply to comment #12) > Sounds like a lot more of a pain than simply enabling DOMi until we're closer > to 1.0 Why would we want to include it now and not in 1.0? Won't there be extension developers using 1.0? I think we should just fix it the right way, instead of postponing the work on it. We need to do it one day anyway.
Since mvl wants to ship DOMi via amo, rather than by default, this bug is WONTFIX. Spinoff to release DOMi-for-Sunbird on amo is bug 354083
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.