Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#441 closed defect (invalid)

Browser support should be primarily by capability and not the user agent string

Reported by: anonymous Owned by: gogo
Priority: normal Milestone: Version 1.0
Component: Xinha Core Version: trunk
Severity: major Keywords:
Cc:

Description

Currently browser detection is done by navigator.userAgent.toLowerCase();

It is much better to test the browsers capabilities rather than relying on a string that can be easily spoofed. Also, by relying on the user agent string any browser that does not contain a tested string will not function even if the browser is capable of running Xinha (i.e. Konqueror).

Change History (2)

comment:1 Changed 14 years ago by gogo

  • Resolution set to invalid
  • Status changed from new to closed

All well and good, but there are situations where "testing for capabilities" isn't good enough. Where the same API is present in (both) browsers but it behaves in different ways - thus we are left either having to test for capabilities that we know are different in order to determine browser so we can use that information to modify behaviour later for other capabilities, or check the useragent. Both are as bad as one another because they do not link the test to the use in any way.

User agent testing is still the best way around this IMHO.

And Konq is in no way capable of running Xinha, neither is Safari (yet, but they are close).

comment:2 Changed 14 years ago by tonyarnold@…

What needs to be done to WebKit? to make safari work? Is there a bug reported at http://bugzilla.opendarwin.org/query.cgi?format=specific&product=WebKit? Let me know, I'm happy to write some regression tests to get this moving for all WYSIWYG input fields in Safari/Konqueror?.

Also, I don't think you've fixed this bug. The original reporter is right about testing for features, not browsers - if the feature is broken in a certain browser, disable it at that point, not right up the chain - it's more code, but less work in the long run (think of JS browser exclusions like unit tests - if any fail, you throw the error, not before).

Note: See TracTickets for help on using tickets.