Bugzilla – Full Text Bug Listing
| Summary: | Prevent application start in unsupported browser (IE6) | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Tim Buschtoens <tbuschto> |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | austin.riddle, bilnoski, cole, tbuschto |
| Version: | 1.5 | ||
| Target Milestone: | 1.5 M6 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Tim Buschtoens
1) I say yes. 2) Just text (no layouting whatsover), it should give a list of supported browser. But should it (by default) be more end-user oriented (like "This application requeires...") or developer-oriented ( "RAP 1.5 requires [...]", perhaps pointing to 1.4 for older browser support)? 3) Can it be hardcoded, or has it to be customizable (e.g. for localization)? Should the check happen before the js has been parsed (to prevent any cases where the parsing might fail in older browser - unlikely), or afterwards (much simpler to implement). It could also be done server side (recognizing the browser from the http-request and responding with a simple html-page). I actually like that last one. Recognizing the client on the server might be useful for non-browser clients. 1) I agree. 2) Can't we avoid the list of supported browsers? This would be another thing to maintain. What about something like: "Unsupported Browser: You're using an outdated browser version that is not supported anymore". I would not mention RAP. Application developers would probably never see this message, only end users. 3) I'd suggest to start with a hard-coded message and make it customizable on request. And I also like the last option. As a RAP application developer I certainly like the idea of having a way to prevent unsupported browsers from loading the application as this is a common practice on the web. However, I am strongly in favor of allowing this feature to be disabled. It should be in the developer's hands to decide whether they want this block for their users or not. (In reply to comment #1) > It could also be done server side (recognizing the > browser from the http-request and responding with a simple html-page). I > actually like that last one. Recognizing the client on the server might be > useful for non-browser clients. I also agree with this approach. I think that there should be a way for individual client implementations to decide what is supported. The application developer needs to have control over the content that is output on non-supported browsers. I know a text-only page that says you cannot use the application with no real explanation of why would not go over well with our clients. I think the best way to handle this is either to allow the developer to specify a URL to redirect to, or specify an html page much like body.html in the current branding. I agree with Austin that the developer should decide which browsers are supported. Maybe in my app I want to disallow IE7 as well because of performance issues. (I only wish we could do this, the reality is we have to support IE7 and adjust our application accordingly). With the protocol this becomes more important since custom widgets might not work properly on all client implementations. So either someone implements a server-side solution which can then later be made customizable, or if there's no time for that i'm going ahead and doing a hardocded client-side solution for the 1.5 release. (In reply to comment #6) > So either someone implements a server-side solution which can then later be > made customizable, or if there's no time for that i'm going ahead and doing a > hardocded client-side solution for the 1.5 release. Again, I think that any solution needs to be governed by the developer. At the very least we should be able to turn this option off. I agree that the problem exists and there is a need for a solution, but I disagree with the approach of hardcoding something that will force "unsupported" browsers to not work. My first question is: What constitutes a "supported" browser, anyway? Is it simply age? performance? features? Is it the case that the browser does not support the RAP protocol and simply can not function? I am okay with blocking browsers/versions such as these. Is it the case that the browser poorly handles some features of RAP or the client-side widget library? I can see a RAP developer crafting a valid RAP app with custom widgets to avoid problems their particular clients have while leveraging the benefits of the entire server-side part of RAP. I use RAP because it is the RCP workbench backing Internet applications, not because I think it's a cool new website development tool. I propose some alternatives. 1) Allow all browsers to connect to the RAP app regardless of browser/version, and let them break. It's up to the application developer to provide the user with "this website works best with" or "this website will not work with" messages. 2) Build in to RAP a way for the developer to provide this message to their clients after the developer's business logic has determined that the browser version provided by the protocol during a connection is not acceptable. 3) Build in to RAP a developer-definable list of browsers/versions supplied via configuration that RAP will check against. If it is missing, any browser is allowed to connect and carry on as much as it will correctly handle. RAP may have a default version of the file with suggestions, but it must be something developers can choose to ignore or replace. In the interest of time and resources, I will accept whatever solution the RAP team can come up with to address the issue, my point on this thread was simply to raise another concern and suggest alternative approaches. However, my team may need to make local modifications with intent to contribute if what is done for the 1.5 release allows for some flexibility. Supported browser are those wich are tested during framework development. Older browser may or may not work. For 1.5 we removed a bunch of IE6-specific code, so there ARE things that wont work there. There was a list of supported browser on eclipse.org/rap, but it seem to be gone now (this must be fixed!). If we allow all browser from scratch, we will probably have to deal with reports about issues in unsupported browser, and application developer might not realize that their application might have problems until the users run into them. We could implement a "use at your own risk" feature to enable older browser, but i wouldn't even go that far. (In reply to comment #9) > If we allow all browser from scratch, we will probably have to deal with > reports about issues in unsupported browser, and application developer might > not realize that their application might have problems until the users run into > them. We could implement a "use at your own risk" feature to enable older > browser, but i wouldn't even go that far. I definitely think that the blocking feature should be enabled by default, so that unaware developers will not be put at risk, but we have to keep in mind, as Ralf said, that this is something that really impacts the end-user. The developers really need a way to disable the feature or customize it at their own discretion because they know their own customers, applications and environment. Along a similar vein, I have already had requests from one of my clients to change the session timeout message so that it is more conformant to their organizational standards. In general, I think we need to be very careful about things like error pages, messages and access controls that make policy decisions that bypass the developer and impact the end user. Changes in CVS HEAD. IE6 (and older) wont't start anymore, message is hardcoded in the JS client. I'm closing this bug as this was about excluding IE6 for 1.5. For any other methods of handling different browser, etc, an enhancment request would be better fit. If someone really want's to run RAP 1.5 in IE6 (which WILL HAVE GLITCHES, possibly crashes), its an easy hack to disable the check. |