This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Auto-detect OS/2 platform | ||
|---|---|---|---|
| Product: | obsolete | Reporter: | _ gtzabari <gtzabari> |
| Component: | collabnet | Assignee: | support <support> |
| Status: | RESOLVED INVALID | ||
| Severity: | blocker | ||
| Priority: | P4 | ||
| Version: | 3.x | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
|
Description
_ gtzabari
2001-03-02 00:54:54 UTC
Gili could you please check if this still does not work? It still does not work. The bottom line reads: Some fields initialized from your user-agent, Mozilla/4.61 [en] (OS/2; U). But the OS still defaults to OTHER At the moment, unless this is a big issue (like causing days of work lost) I am inclined to spend our resources in other directions. This is an opportunistic change that should happen to the Bugzilla code as it exists and then we could apply a patch, but at this point, I don't think this is an effective use of our resources. Are you available to make this change now? This issue hasn't cost me "hours" yet, but it has cost me at least 30 mins with the number of bugs I report on a regular basis. Since you are in no rush for build 3.3 (the release date is far off) perhaps you can take a look at this now? Moving this to P5, because of the very few people it impacts. We can enter this as a request for a future upgrade, but this won't be completed in the timeframe of the next upgrade. Changing this to an enhancement request, as it is currently working-as-designed. Internal CollabNet issues SC63, SC4511. This is entered as a request in the SC 2.0 product map. Hey, I'm offended by that comment :) A lot of people use OS/2 <grin> Anyway, on a more serious note I don't see why you change this from NEW to RESOLVED as the feature request was _not_ resolved as of yet. Shouldn't it remain OPEN? RESOLVED REMIND is (our) standard for issues which have been requested, but will not be brought up in the short term. We do check on these issues regularly to see whether "their time has come". *** Issue 15257 has been marked as a duplicate of this issue. *** Reopening all RESOLVED REMIND Issues and marking them P5. Accepting issue. If I may add some more info, using Mozilla 0.9.5 under OS/2 (my previous report was under Netscape 4.61 for OS/2) the identification string is: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:0.9.5) Gecko/20011016 RPT-HTTPClient/0.3-2. Once again, I think the key is to look for (OS/2, ...) in the brackets and ignore the actual browser itself. Since the identification string reported by browsers is so free form, the developer found that this was a much more difficult problem than previously thought. We have basically solved this in the following way: The Platform and OS will default to All the first time you submit a bug with a particular browser; but if your browser accepts cookies, the choices will "stick" when you submit future bugs. The identification string for the operating system (not browser!) is quite easy to extract. Just grab the first string inside the brackets. No matter what browser the user is using, the first string will read "OS/2" Unfortunately, since the "OS" field that we're mapping to is a limited list (a pull-down menu), and the end user can often set the identification string to anything he wants, we've found it's a significant task to map anything like the majority of situations to a limited list. Besides, many customers want to change this list to their favorite OS's, and there's no good way to accomodate this while having an auto-detect system. Very well, so please make sure the cookie you use: 1) Is persistent, even if the browser is closed. 2) Can be changed over time. The cookie really only stores the OS choice used in the previous bug report. That way if a user reports issues for multiple OSs, it'll remember the last one he reported and vary over time. [ Just my 2 cents ] I've confirmed both these features with the programmer. This has been fixed in the 2.0 release of SourceCast. During the upgrade to that release we can verify or reopen if necessary. Have we upgraded to SourceCast 2.0? I have noticed now OS is properly detected as "OS/2" but PC is still being detected as "Other". If we have indeed upgraded, then this issue should be reopened. Gili, Netbeans is currently running version 1.1.3 of SourceCast. Currenly when a user posts an issue, a cookie is set with the values for these fields to be used on subsequent posts; Currently, the default is always the value used in the most recent post. So these values once set, they need not be set everytime an issue is filed. The Operating Systems values is pulled from the list present at: http://www.netbeans.org/issues/editattributes.cgi?table=opsys Marking as verified We recently moved out from Collabnet's infrastructure |