Community
Participate
Working Groups
At a time when web development is more important than ever, Eclipse platform support for web browsers is weak. The preferences panel under Window > Preferences > General > Web Browser has some limitations: 1) The dialog that pops up has only a tiny window for parameters 2) The documentation seems to be limited to two lines of text in the dialog box. 3) The parameters are ignored in some cases (even if we knew what the mean) 4) The search button on the preference panel doesn't work. 5) The mechanism for finding browsers does not work on linux for the most part. Rather than filing and fixing these problems, my suggestion is to take advantage of Eclipse's powerful launch configuration mechanisms. By creating a LaunchConfigurationType for each of the common browsers and one generic one, the General > Web Browser panel could be populated with instances of LaunchConfiguration for browsers found in the users machines (as now with the BrowserDescriptors). The New button could bring up the familiar UI of Run limited to the configurations of browser types. Edit would be edit on launch configuration; remove well that would delete the configuration. The LaunchConfigurationTypes could have a bit of UI control for the common browser command line features used by developers (eg for Firefox profile and profile directory) as well as "arguments" as string for exotica. The result would be a much more powerful web browser interface and a UI that more familar, documented, and maintainable than the current crusty code.
Its an interesting idea but its different in a few ways from the way we normally approach configuration. I'd consider the web browser parameters being closer to configuration of say OLE, since its about configuration of an external embeddable application which is embedded in our environment. Instead, launch configurations are for running things outside of the environment, which get their own startup, JVM, etc. Boris, any thoughts?
(In reply to comment #1) > Its an interesting idea but its different in a few ways from the way we > normally approach configuration. I'd consider the web browser parameters being > closer to configuration of say OLE, since its about configuration of an > external embeddable application which is embedded in our environment. Instead, > launch configurations are for running things outside of the environment, which > get their own startup, JVM, etc. > The General > WebBrowser has two categories, "internal" and "external" As far as I know, the external browser category only includes programs running in other processes while the internal category is a singleton built-in mozilla browser control. My proposal refs to the External Web browser part of the preference. I don't know much about alternatives/configuration of the internal browser.
The preference page in question comes from User Assistance so I am moving this enhancement request to their inbox. In terms of plugin dependencies, the launch configuration dialog cannot be used just because User Assistance is lower in the stack than Debug, which contributes the launch framework. I agree that the current preference page could be improved. Maybe someone from WTP can help us out here? David?
Thanks for thinking of us Boris ... nothing comes to mind right off, but will add two to CC list in case they have ideas. Tim has a long history with the browser (for "launching" web pages) and Dave Carver has some general ideas about "launch" (but, not sure this general ... just making if free of JDT). But ... just in case, Tim or Dave if you have any ideas please document them here.
(In reply to comment #3) > In terms of plugin dependencies, the launch configuration dialog cannot be used > just because User Assistance is lower in the stack than Debug, which > contributes the launch framework. I wonder it this dependency is out of date? 'Help' now provides a fallback internal browser and it has its own UI (Window > Preferences > Help) allowing users to override the default. If we had an IWebBrowserLaunchConfiguration that provides IBrowserDescriptor then built the General > WebBrowser UI from these, then only the UI would need to be lifted. Even the current extension point could be supported by creating IWebBrowserLaunchConfiguration from the markup designed from IBrowserDescriptor. (Ideally we would not want IBrowserDescriptor to become API if that can be avoided).
If we haven't had contributions to improve the docs or fix bugs in it's current location, switching to launch configs isn't going to improve the situation; we'll just be starting over again. I think I'd need to better understand the motivation for moving the UI from preferences to launch configurations and what benefit we'd expect to see from that. Note that user-initiated launches are only one path of browser usage. The browser is frequently opened through actions like help, JDT, PDE docs, or Run on Server, and the usability of these cases (e.g. do we clutter the debug view with other launches) needs to be considered as well.
(In reply to comment #6) > If we haven't had contributions to improve the docs or fix bugs in it's current > location, switching to launch configs isn't going to improve the situation; > we'll just be starting over again. I think I'd need to better understand the > motivation for moving the UI from preferences to launch configurations and what > benefit we'd expect to see from that. Sorry I was not clear. I don't want to move the UI. Rather I want the current UI to list IWebBrowserLaunchConfigurations which fulfill IBrowserDescriptor but allow full LaunchConfiguration capabilities. > > Note that user-initiated launches are only one path of browser usage. The > browser is frequently opened through actions like help, JDT, PDE docs, or Run > on Server, and the usability of these cases (e.g. do we clutter the debug view > with other launches) needs to be considered as well. > Indeed, it is exactly these other cases that I am targeting. Rather than have these other paths create new confusing UI for web browser launching, we can update the General > WebBrowser which is any way where users expect to look for configuring web browsing. But they can't be very successful with the current limited API.
I agree that the current browser preference page is confusing to say the least, it even has some side effects that most users are not aware of. I would love to rewrite this preference page but I'm not sure I have the spare time to do this for Eclipse 3.5.
I'm considering developing and contributing a modestly improved WebBrowserPreferencePage. I'd like to explore what would have the best chance for success. Overall I want to support existing function and allow new function through creation of a browser via LaunchConfigurations. The new panel would be similar to the current one, but the items on the browser list could be a mix of BrowserDescriptor-s (current model) and WebBrowserLaunchConfiguration-s (new model). New... would create a new WebBrowserLaunchConfiguration Edit... would edit either Remove would remove either type Search would populate with WebBrowserLaunchConfiguration Restore Defaults would create BrowserDescriptors Apply would save BrowserDescriptors as now. I would propose to change the UI to a single-select list with the first item "Use internal Web Browser" I think this design could fall back gracefully if Debug was absent. I would appreciate feedback on whether and how to proceed to maximize potential uptake by eclipse.
I cannot speak for Platform UA, but it seems like we should add Darin for the Debug aspect of this.
I believe the launch framework could be used to configure browser launching (I'm not sure it's the right thing to do though). * The launching framework is general, and is designed to launch things in and out of prcoess. For example, the external tools Ant launcher can launch an Ant build in the same VM as Eclipse, or in a seperate VM. * The framework allows lauches to be silent/private. Most launches end up in the launch history and debug view, but this can be suppressed. * We offer an API launch dialog that can be used to edit one configuration at a time (for example, see the "Run/Debug Setttings" via the "Properties..." of a resource). This is the style of editing I think you would want to use in the preference page. * Launch configurations are persisted locally with workspace metadata (or as a resource in the workspace). This may be an issue, as you will want to be able to export/import the browser settings as preferences. With that said, we do have support to export/import launch configurations - but you might need some extra flexibility here. I had not thought of using launch configurations for launching editors/browsers in the IDE. However, they are definitely use to launch external editors already (via external tools). In the longer term, this is another argument for creating a launching plug-in seperate from debug (others have also wanted this).
(In reply to comment #11) > I believe the launch framework could be used to configure browser launching > (I'm not sure it's the right thing to do though). While I believe the best design would use the launch framework to configure browser launching, I'm actually proposing "and" here, current+launch config. > > * The launching framework is general, and is designed to launch things in and > out of prcoess. For example, the external tools Ant launcher can launch an Ant > build in the same VM as Eclipse, or in a seperate VM. > * The framework allows lauches to be silent/private. Most launches end up in > the launch history and debug view, but this can be suppressed. Perhaps we can allow users to select this? I don't know if this can be set at run time. > * We offer an API launch dialog that can be used to edit one configuration at a > time (for example, see the "Run/Debug Setttings" via the "Properties..." of a > resource). This is the style of editing I think you would want to use in the > preference page. Yes, that was my plan > * Launch configurations are persisted locally with workspace metadata (or as a > resource in the workspace). This may be an issue, as you will want to be able > to export/import the browser settings as preferences. With that said, we do > have support to export/import launch configurations - but you might need some > extra flexibility here. exporting would be advantageous for users with multiple workspaces or who are migrating to a new workspace. less so for other purposes since the launch config has machine-specific paths. > > I had not thought of using launch configurations for launching editors/browsers > in the IDE. However, they are definitely use to launch external editors already > (via external tools). In the longer term, this is another argument for creating > a launching plug-in seperate from debug (others have also wanted this). I have quite a bit of experience in launching Firefox with launch configurations under program control and I've even written a Firefox specific UI if we want to go to that extreme. But for the first cut I propose to make the UI simple and to not wait for work on other plugins to proceed here.
One reason the browser preference page is the way it is is that the choice of external browser affects both the open with browser command and the Eclipse help system. There are seperate preferences to use an external browser on the Web Browser preference page and also on the help preference page. This is why we don't disable the list of external web browsers on the Web Browser page when you select Use internal web browser. This also means that having a single list of checkboxes, one of which is "internal browser" won't work for the help system. Another strange aspect of the current design is that with default preferences the open with menu for a .html file contains a menu item for "Web Browser" which will open an internal browser if possible. If you set the preference to open using an external browser, hit OK and then set the preferences back to use internal browser the open with menu gets an additional entry - "Internal Browser" and at this point in time both Internal Browser and Web Browser will do exactly the same thing. It would seem that it would be better to always have two items on the open with menu "Internal Browser" and "External Browser" and not have the radio buttons on the browser preference page for internal/external. It does seem that the add external browser dialog could be improved significantly. Your comment about the parameters being ignored in some cases should no longer be true, see Bug 238452.
(In reply to comment #13) > One reason the browser preference page is the way it is is that the choice of > external browser affects both the open with browser command and the Eclipse > help system. There are seperate preferences to use an external browser on the > Web Browser preference page and also on the help preference page. This is why > we don't disable the list of external web browsers on the Web Browser page when > you select Use internal web browser. This also means that having a single list > of checkboxes, one of which is "internal browser" won't work for the help > system. Yes I remember that after a bit. I think the UI can be improved slightly however. > > Another strange aspect of the current design is that with default preferences > the open with menu for a .html file contains a menu item for "Web Browser" > which will open an internal browser if possible. If you set the preference to > open using an external browser, hit OK and then set the preferences back to use > internal browser the open with menu gets an additional entry - "Internal > Browser" and at this point in time both Internal Browser and Web Browser will > do exactly the same thing. > > It would seem that it would be better to always have two items on the open with > menu "Internal Browser" and "External Browser" and not have the radio buttons > on the browser preference page for internal/external. But you still have the problem that the user has to give a default external browser for cases where internal cannot be used right? So you still need the pref UI to allow internal + one external-for-cases-where-internal-cant be used. > > It does seem that the add external browser dialog could be improved > significantly. Your comment about the parameters being ignored in some cases > should no longer be true, see Bug 238452. Thanks! However the parameter box is way too small. The smallest set of arguments I is: -jsconsole -chrome chrome://chromebug/content/chromebug.xul -p chromebug1.4 -firefox and it overflows the tiny window. I have cases with about three times that size because of a long path. (also the %url% stuff is still a mystery). I'll investigate whether the only fix I need is a larger parameter box. That would be a lot simpler...
Created attachment 119847 [details] patch to BrowserDescriptorDialog allowing long parameter lists Here is a patch to allow the parameters text box to grow as the user resizes the dialog. Horizonatal resize will help with long paths on the executable field. I think the parameter field should be initialized large if the incoming text is long. (rather than require scrolling). Comments? What would be needed to convince someone to accept something like this for eclipse?
Created attachment 119848 [details] patch to BrowserDescriptorDialog allowing long parameter lists and setting inital size based on incoming text Added code to set initial size
I'll take a look over the patch and assuming it's OK I'll commit it for the next milestone.
Created attachment 120526 [details] Modified patch I made two additional changes: Only one of the two constructors added the SWT.RESIZE bit to the shell, I have modified the second constructor also. One constructor is used for new and one for edit. I added SWT.WRAP to the style of the multiline text box. Can you test this latest patch and see if you agree with my changes?
Looks good. The only problem I had was caused by the version number on the plugin not being updated.
Patch committed to HEAD, Fixed.
