#13494 closed defect (fixed)
Broken on Internet Explorer version 8
Reported by: | solstice333 | Owned by: | Jon Ashley |
---|---|---|---|
Priority: | normal | Component: | KeepInterfaceSimplePlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 1.2 |
Description
Hiding fields with the visible
property is broken on internet explorer. The fields are still exposed.
Attachments (2)
Change History (27)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
I have tried to reproduce this on Internet Explorer version 11 (version 11.0.9600.19129), but without success.
Can you please press F12 while viewing the ticket in IE to bring up the developer console. Click on the 'Debugger' tab, then click on the little folder icon near the top left corner of the main debugger window. This should list all the scripts that are currently loaded.
Can you please confirm that the scripts kis.js
and bluebird.min.js
are both present in the list. (The bluebird.min.js
script only loads when using the Internet Explorer browser.)
comment:4 Changed 6 years ago by
Hm, maybe this isn't worth fixing but rather looking for some cheesy workaround. Basically some consumer is using some old version of IE to submit the cc field and it's spamming too much. I confirmed both kis.js and bluebird.min.js are loaded.
comment:5 follow-up: 10 Changed 6 years ago by
Alright, SimpleTicketPlugin seems to be a decent workaround for now. I just want to make it so some normal user without the TICKET_EDIT_CC permission, cannot create a ticket that has a bunch of email addresses in the cc field. The user who's doing this is probably using some old version of IE and is able to get around kis features. That said, kis is the only plugin I can find that does any sort of field hiding bound to the ticket state. SimpleTicketPlugin is good enough for hiding fields at the ticket <none>
state even on old IE.
comment:6 Changed 6 years ago by
OK, I think the problem is likely to be the ancient version of Internet Explorer, and the fact that it isn't quite compatible with the Bluebird library. From the Bluebird website:
IE7 and IE8 do not support using keywords as property names, so if supporting these browsers is required you need to use the compatibility aliases:
Promise.try() -> Promise.attempt()
.catch() -> .caught()
.finally() -> .lastly()
.return() -> .thenReturn()
.throw() -> .thenThrow()
The kis plugin definitely uses the .catch
method in two places, so won't work as-is on IE7 or IE8. I might be able to do something about this. I will have a look at it over the weekend.
As for 'cheesy workarounds'... if you are willing to give it a try, you could edit the file kis.js
in the plugin source and remove the two .catch()
clauses that are in there (delete everything from the full-stop before catch
up to but not including the semi-colon on the next but one line). This will remove some of the plugin's ability to catch and report errors, but you probably don't need that anyway. Don't change catch
to caught
as suggested by the Bluebird website, as that will break the plugin for every browser that isn't Internet Explorer.
comment:7 Changed 6 years ago by
Status: | new → accepted |
---|---|
Summary: | broken on internet explorer → Broken on Internet Explorer version 8 |
This plugin will not be supported for versions of Internet Explorer older than version 7, as Bluebird doesn't officially support these. There are anecdotal reports that Bluebird does in fact work with Internet Explorer 6 and Netscape 7.
comment:8 Changed 6 years ago by
Ah I see. Yeah, I'll try the workaround you suggest if for some reason the supposed-to-be-hidden-fields in the other ticket states (aside from newticket) become problematic, but so far it's just been that damn cc text field that's been bad.
Hm, seems like there's only two options as far as catching the rejected promise. What about trying to call .catch and if that fails call .caught? For instance,
function mockReject() { return new Promise((resolve, reject) => { throw new Error("foo error") }); } let p = mockReject(); try { p.catch(e => console.error(e.message)) } catch (e) { if (e instanceof TypeError) { p.caught(e => console.error(e.message)) } else { throw e } }
I figure it'll throw some kind of error that you can catch and duck type again.
Anyway, no rush. Thanks for looking into this. I appreciate it. Let me know if I can provide any more information.
comment:10 follow-up: 11 Changed 6 years ago by
Replying to solstice333:
Alright, SimpleTicketPlugin seems to be a decent workaround for now. I just want to make it so some normal user without the TICKET_EDIT_CC permission, cannot create a ticket that has a bunch of email addresses in the cc field. The user who's doing this is probably using some old version of IE and is able to get around kis features. That said, kis is the only plugin I can find that does any sort of field hiding bound to the ticket state. SimpleTicketPlugin is good enough for hiding fields at the ticket
<none>
state even on old IE.
I have put a patch on the trunk (see above), which I think doesn't break for existing browsers. I can't test it on Internet Explorer 7 or 8, so please let me know if it works for you.
I have also put a fix into the way the Warden rules operate, because from your comment above, I think you might be better off using a Warden rule to enforce the ticket creation restriction. Users can get around any Assistant rule just by turning off Javascript, but getting aroung the following rule won't be so easy:
[kis_warden] can't set initial cc list = _status == '' && cc && !has_role('TICKET_EDIT_CC')
Without the fix, this rule doesn't work because _status
doesn't evaluate to an empty string.
comment:11 follow-up: 12 Changed 6 years ago by
Replying to Jon Ashley:
Replying to solstice333:
Alright, SimpleTicketPlugin seems to be a decent workaround for now. I just want to make it so some normal user without the TICKET_EDIT_CC permission, cannot create a ticket that has a bunch of email addresses in the cc field. The user who's doing this is probably using some old version of IE and is able to get around kis features. That said, kis is the only plugin I can find that does any sort of field hiding bound to the ticket state. SimpleTicketPlugin is good enough for hiding fields at the ticket
<none>
state even on old IE.I have put a patch on the trunk (see above), which I think doesn't break for existing browsers. I can't test it on Internet Explorer 7 or 8, so please let me know if it works for you.
I have also put a fix into the way the Warden rules operate, because from your comment above, I think you might be better off using a Warden rule to enforce the ticket creation restriction. Users can get around any Assistant rule just by turning off Javascript, but getting aroung the following rule won't be so easy:
[kis_warden] can't set initial cc list = _status == '' && cc && !has_role('TICKET_EDIT_CC')Without the fix, this rule doesn't work because
_status
doesn't evaluate to an empty string.
Thanks, I'll get to this eventually. Need to finish a few things first.
comment:12 Changed 6 years ago by
Replies inline...
Replying to solstice333:
Replying to Jon Ashley:
Replying to solstice333:
Alright, SimpleTicketPlugin seems to be a decent workaround for now. I just want to make it so some normal user without the TICKET_EDIT_CC permission, cannot create a ticket that has a bunch of email addresses in the cc field. The user who's doing this is probably using some old version of IE and is able to get around kis features. That said, kis is the only plugin I can find that does any sort of field hiding bound to the ticket state. SimpleTicketPlugin is good enough for hiding fields at the ticket
<none>
state even on old IE.I have put a patch on the trunk (see above), which I think doesn't break for existing browsers. I can't test it on Internet Explorer 7 or 8, so please let me know if it works for you.
Okay, I tried the one in trunk on IE8. Same behavior -- the cc field is not hidden on IE8 , but is hidden, as expected, on firefox. In other words, same behavior.
I have also put a fix into the way the Warden rules operate, because from your comment above, I think you might be better off using a Warden rule to enforce the ticket creation restriction. Users can get around any Assistant rule just by turning off Javascript, but getting aroung the following rule won't be so easy:
[kis_warden] can't set initial cc list = _status == '' && cc && !has_role('TICKET_EDIT_CC')Without the fix, this rule doesn't work because
_status
doesn't evaluate to an empty string.
Thanks, the warden works great as you suggested. I'll use this alongside the SimpleTicketPlugin just in case.
Thanks, I'll get to this eventually. Need to finish a few things first.
comment:13 Changed 6 years ago by
Let me know if you want to go through another cycle of testing. I have the environment set up for it.
comment:14 Changed 6 years ago by
Rats. I thought that would fix it. I don't suppose their are any error messages in the IE8 JavaScript console that might shed some light on this? I can't even remember if IE8 has a JavaScript console.
If not, I'll have to see if I can maybe set up an IE8 environment somehow for testing.'
Changed 6 years ago by
comment:15 Changed 6 years ago by
comment:16 Changed 6 years ago by
What about instead of doing window.Promise.prototype.catch
, you do window.Promise.prototype["catch"]
?
comment:17 Changed 6 years ago by
That sounds hopeful. IE shouldn't be executing the failing line, so it must be getting picked up in an initial syntax check. I think you are right and accessing the 'catch' property that way should evade such a check. Can you give that a try and let me know if it works please?
Changed 6 years ago by
Attachment: | error_then.PNG added |
---|
comment:19 Changed 6 years ago by
That's very odd. I'm going to try and install IE8 myself so that I can look at this properly. Can you confirm that Bluebird is still getting loaded in IE? (The error above looks as though the return statement has caused the problem, but that's even harder to believe.)
comment:20 Changed 6 years ago by
Managed to reproduce this eventually. It turned out to be the bind()
method that is causing the problem, not then()
; apparently IE8 doesn't implement it. There are other problems, such as the jQuery prop()
method not working.
The good news is that a polyfill to implement bind()
fixes the error. The bad news is that having done so, the field-hiding behaviour for the plugin still doesn't work on IE8. I am still hoping this can be sorted out, but the IE8 debugging environment is poor so it may take a while.
comment:21 follow-up: 22 Changed 6 years ago by
The most recent commit on the plugin trunk works for me with IE8. The changes are:
- remove trailing commas from list items (IE8 rejects them in compatibility mode);
- use
$.bind()
instead of$.on()
if the version of jQuery present is lacking.on()
; - use
$.attr()
instead of$.prop()
on Internet Explorer; - provide a polyfill for Javascript's
.bind()
on Internet Explorer.
Can you please give it a try and confirm here that it works for your user? Thanks.
comment:22 Changed 6 years ago by
Replying to Jon Ashley:
The most recent commit on the plugin trunk works for me with IE8. The changes are:
- remove trailing commas from list items (IE8 rejects them in compatibility mode);
- use
$.bind()
instead of$.on()
if the version of jQuery present is lacking.on()
;- use
$.attr()
instead of$.prop()
on Internet Explorer;- provide a polyfill for Javascript's
.bind()
on Internet Explorer.Can you please give it a try and confirm here that it works for your user? Thanks.
Thanks. Trying this out now. I'll let you know if it works for me too.
comment:23 Changed 6 years ago by
Ok, it seems like whatever is in trunk is working for me. Just did some light testing on firefox and IE8. Thanks! I believe you can close this ticket as fixed.
comment:25 Changed 6 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Can you please tell me which version of Internet Explorer you see this on? Thanks.