Although it is SMF policy that stable releases will only receive official security patches, it has been decided to offer some fixes for other problems that have become apparent since 2.0.x was originally released.

These fixes will be offered as separate mod packages, for installation via the usual package manager process (of course anyone is free to propose bug fixes at discretion in mods or through the Tips and Tricks board).

Please note that SMF will not be attempting to fix absolutely every minor bug in 2.0.x, and fixes will be offered at the team's discretion.

---

Two things that are particularly relevant these days are new versions of Internet Explorer, and detection of phones and tablets.

A mod has been packaged to update the browser detection array in Load.php, to enable detecting a broader range of browsers and devices.

This includes detecting versions of Internet Explorer up to the not-yet-released IE11, and correction of the existing $context['browser']['ie_standards_fix'] so that it only targets versions earlier than IE8.

There is also the option of using a $context['browser']['is_mobile'] and $context['browser']['is_tablet'] setting in custom coding, if desired. These two settings cover a useful range of devices and browsers, and there are more specific settings in the main array as well.

The package for updating browsers and device detection is named detectBrowser_update.zip, and is attached to this post.

---

A second package is also available, named IE9_calendar_fix.zip.

This updates some template and CSS details, which were problematic if IE9 and IE10 detection were enabled with no other changes. The fix has been tested in LTR and RTL languages, and in all currently used versions of IE, Safari, Opera, Firefox and Chrome.

This package also includes a minor CSS fix for anyone who uses the sidebar menu option on a narrow screen.

Sneaked this in.

Thanks for putting this fix together.

I like the idea!

Awesome thanks!

Thanks for this... I will translate this and post in spanish board.

Yes thanks!
great deal good looking out!

Regards,
maxx

Basic CSS fix for a minor bug in Chrome - 2.0.x category header text mis-aligning when expand/collapsing.

Quote from: Antechinus on June 07, 2013, 08:27:05 PM
Ok, solution. In index.css find:

Code Select Expand

/* Styles for rounded headers.
------------------------------------------------------- */
h3.catbg, h3.catbg2, h3.titlebg, h4.titlebg, h4.catbg
{
overflow: hidden;
height: 31px;
line-height: 31px;
font-size: 1.2em;
font-weight: bold;
}
h3.catbg a:link, h3.catbg a:visited, h4.catbg a:link, h4.catbg a:visited, h3.catbg, .table_list tbody.header td, .table_list tbody.header td a
{
color: #fff;
}

Add after:

Code Select Expand

h3.catbg a:link, h3.catbg a:visited
{
display: inline-block;
}

Tested in latest FF, Chrome, Opera, IE9 and IE8 emulation and IE7 emulation. Works in all of those. Should be fine in Safari too.

Haven't checked everywhere else in the theme, so if it breaks somewhere else with the added css it will be easy to alter the code to only target the board index.

ETA: This should also work in any custom themes that have the same buglet.

Thanks for these patches!!   Wonder why these didn't make it into the SMF 2.0.5 update....

EDIT: Would love to suggest sticky-ing this topic.....

I'm guessing nobody remembered these patches when we were working on things for 2.0.5.

Did any of these make it into v2.0.6?

EDIT: Nope.... Just looked....  Still left out 

Sadly not, but I did have like a dozen things to get fixed in 2.0.6 and none of them were aesthetic things.

There are also very serious practical issues with pushing patches out that affect themes for the simple reason that almost everyone is using a custom theme - and it may or may not fix the problem - and may make it much worse.

Not trying to sound ungrateful, because I really am grateful....  Didn't think about the effect that these patches might have on non-standard themes....   Thanks again!

It's all good Just patching is a tricky business

Unless it's a legitimate issue a template itself (like 2.0.6's Help.template.php fix), the odds are pretty firmly that we'll leave it alone to avoid breakage - that way, anyone who does want it fixed can get it fixed and we can deal with the issues case-by-case if they arise.

Yep, though that one is not only a template thing: the "main fix" is browser (IE in particular) detection that fixes an accessibility issue (i.e. sounds (in captcha) are not played in IE >...8 I think, don't remember exactly). This fix causes a template issue in the calendar. That is an example of how tricky patching is, and how tricky support many things is.

Ah, I missed that in amidst all the other stuff that had to be fixed >_<

It's not quite November 5th when we can not forget the Gunpowder Plot

Does anyone know if the patch by Antechinus (detectBrowser_update.zip, listed in the first post here) is safe to use with SMF 2.0.6?

I've noticed that WYSIWYG (rich text editing) doesn't currently work with Internet Explorer 11 in Windows 8 (with SMF 2.0.6). A pop-up message indicates that it's not possible. Apparently this is due to a problem with browser detection.

Thank you for any help.

Should be safe, although I haven't actually tried it. All it's doing is allowing more browsers to be detected. In theory you should be able to add as many to the array as you like.

Quote from: Chainy on November 09, 2013, 08:47:24 PM
I've noticed that WYSIWYG (rich text editing) doesn't currently work with Internet Explorer 11 in Windows 8 (with SMF 2.0.6). A pop-up message indicates that it's not possible. Apparently this is due to a problem with browser detection.

IE11 doesn't contain MSIE in user agent string and not detected as known IE browser.

Quote from: Antechinus on November 10, 2013, 03:02:48 PM
Should be safe, although I haven't actually tried it. All it's doing is allowing more browsers to be detected. In theory you should be able to add as many to the array as you like.

Thanks, Antechinus. So, as I understand it, this patch will probably do the job (fix the WYSIWYG problem in IE 11) - it just needs a bit of testing first of all.

Quote from: digger on November 10, 2013, 03:54:02 PM

Quote from: Chainy on November 09, 2013, 08:47:24 PM
I've noticed that WYSIWYG (rich text editing) doesn't currently work with Internet Explorer 11 in Windows 8 (with SMF 2.0.6). A pop-up message indicates that it's not possible. Apparently this is due to a problem with browser detection.

IE11 doesn't contain MSIE in user agent string and not detected as known IE browser.

This is kind of a major bug, isn't it? Internet Explorer is an important browser to support.

http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0

You mean the whole 1.5% of users that use it?

Quote from: Arantor on November 10, 2013, 04:14:54 PM
http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0

You mean the whole 1.5% of users that use it?

IE11 released for Windows 7 that means IE10 sooner become IE11. Probably IE11 become 20% (according to data graph you linked).

Quote from: Antes on November 10, 2013, 05:02:51 PM

Quote from: Arantor on November 10, 2013, 04:14:54 PM
http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0

You mean the whole 1.5% of users that use it?

IE11 released for Windows 7 that means IE10 sooner become IE11. Probably IE11 become 20% (according to data graph you linked).

Indeed. So maybe not a major bug now, but in a few months.

Despite IE11/Win7 being crippled compared to IE11/Win8, you mean - http://www.theregister.co.uk/2013/11/11/ie11_features_not_for_win7/

People upgrade their browser and operating system when asked to. And they don't seek that kind of information.

Going from Windows 7 to Windows 8 is not free. Gotta have a reason to have such an upheaval.

I was more thinking about patches.

So I'll just write IE11 for W7 off in the same category I've always filed IE in: a POS crippled browser that's always trying to play catch up with the decent ones. Nothing to see here. Yawn.

The only reason IE is on my box is because it came with the OS. If not for that, I'd never bother installing it.

Ok, I've had another look at the packages in the OP, and updated the browser detection package to handle IE11's actual user agent, not the one we thought it would have at the time (when IE11 hadn't actually been released).

Also threw in detection for Pale Moon. Probably wont ever be really necessary, but since I'm running Pale Moon now (and loving it) I thought it should go in, just in case.

Will submit the revamped packages to the Mod Site as usual. They're potentially very useful, and don't seem to be getting much attention tucked away in here.

Thank you and Glad you are working with these things... great news!

regards
stMaxx

Thank you, Antechinus. I'm sure many people will find this very useful. I wonder how 2.1 will handle this?

Aside from the obvious fact that it could even be tested since it's on Github (and testing is something is apparently such a huge hurdle that any testing would be welcomed), 2.1 detects IE11 just fine, and doesn't detect Pale Moon specifically because it generally projects itself as Firefox and should generally have the same rendering characteristics and behaviours (which is all the browser detection is really for anyway) and any test for is_ff should generally work and apply to Pale Moon or similar.

As far as post 2.1 release, we'll be in exactly the same situation as 2.0 is currently in unless the policy of the team is altered to have 2.1.x patches be for bug fixes, something I was always keen on but this was not especially welcomed IIRC.

Arantor, I think there are some sites which make it possible to test with Internet Explorer (for people like me that don't have access to Windows). Do you know of a particular site that you'd recommend for this?

BrowserShots.org is the go-to but that's only any good for rendering of guest-visible content. Some of the more intricate behaviours under the hood can't be tested that way.

For example, attachment serving physically behaves differently between the major browsers because of the way SMF sends the Content-Disposition header (and it's still just as messy these days if you have mixed encoding risks)