Can you provide a complete but minimal test case on jsFiddle.net and instructions for reproducing the problem? Please don't include any other third-party libraries, they may be a component of the problem.

Replying to [comment:1 dmethvin]:

Can you provide a complete but minimal test case on jsFiddle.net and instructions for reproducing the problem? Please don't include any other third-party libraries, they may be a component of the problem.

Nope, sorry. We already spent several hours in finding solution and provided you with exact code that fixes the issue and we are not willing to spend more time on making some minimalistic sample. Yes, it is probably caused by the complexity of our product but you have all you need to fix it. It is now up to you whether you are willing to spend your time on fixing your own product or wait until someone else reports it and spend the same hours as we did on finding that it is the very same issue after all ;-)

We are not sure whether it is a bug in "our own product" (which you are using for your own benefit, provided for free and lovingly maintained by us), which is why we asked for a simplified test case that reproduces this issue.

If you're not willing to provide one to see that this is fixed, then we WILL wait until someone else reports it and spends the same hours as you did, and who is willing to work with us on resolving this issue instead of providing us with a vague, unactionable report.

I said good day.

Replying to [comment:3 mikesherov]:

We are not sure whether it is a bug in "our own product" (which you are using for your own benefit, provided for free and lovingly maintained by us), which is why we asked for a simplified test case that reproduces this issue. If you're not willing to provide one to see that this is fixed, then we WILL wait until someone else reports it and spends the same hours as you did, and who is willing to work with us on resolving this issue instead of providing us with a vague, unactionable report. I said good day.

No problem, your choice, though not at all motivational for us to report anything else in future. Also a good example of how ego makes open source projects not caring about the quality ... you should be very proud of yourself now ...

Replying to [comment:5 anonymous]:

Replying to [comment:3 mikesherov]: > We are not sure whether it is a bug in "our own product" (which you are using for your own benefit, provided for free and lovingly maintained by us), which is why we asked for a simplified test case that reproduces this issue. > > If you're not willing to provide one to see that this is fixed, then we WILL wait until someone else reports it and spends the same hours as you did, and who is willing to work with us on resolving this issue instead of providing us with a vague, unactionable report. > > I said good day. No problem, your choice, though not at all motivational for us to report anything else in future. Also a good example of how ego makes open source projects not caring about the quality ... you should be very proud of yourself now ...

Not about quality here. It's about how we can't take action without a test case that can reproduce this issue considering the overwhelming volume of bug reports we get, and work on, in our free time. Reports from people who are unwilling to work with us, and who tell us to fix bugs in our product despite not providing any actionable steps and take umbrage when repro steps are requested, are not reports we are going to act on.

Simply, we will wait till someone can provide us actionable steps, as many people do. If there is a bug in jQuery here, someone will report it, and they'll be willing to provide repro steps.

The way we do work here is create a failing unit test first, so the same regression doesn't happen in the future. Without repro steps, we can't create a test. You have asked us if your fix is "correct". We can't even begin to answer that question until we see how and why it's breaking in the first place. Yes, the fix may cause adverse side effects. Maybe not for you. But it won't be in jQuery core unless it can be proven how it's broken.

If instead you are asking us if your fix would work for JUST you, then ask that in the forum. This is the bug tracker, where people are trying to fix issues in jQuery proper, and are expected to follow the bug reporting guidelines:

"Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket."

There really isn't much we can do to fix the problem until we can reproduce it. It's pretty rare that someone outright refuses to provide a test case so that we can help them; color me stunned. A few copy-pasted lines isn't "all we need to fix it."

Would this be something encountered by Kentico's customers or developers? Looks like there's a @kentico_devnet on Twitter, perhaps we can get their help if you're too busy.

Replying to [comment:5 anonymous]:

No problem, your choice, though not at all motivational for us to report anything else in future. Also a good example of how ego makes open source projects not caring about the quality ... you should be very proud of yourself now ...

In fact, we are very proud of the work that Mike contributes to the project and the lengths he's willing to go to help others. Perhaps you weren't aware, but jQuery core is all volunteer, which means we do this for free in our available spare time.

Refusal to provide a reduced test case is anti-open source.

Refusal to provide a reduced test case is anti-open source.

Hear, hear!

Hey Martin,

Firstly, I know reducing down bugs from a CMS is quite tricky. It's awesome that the initial report includes the fix at a micro level.

Now, for the jQuery team to fix this, there will need to be a unit test accompanying any patch, so getting something reduced that can be adapted for the test suite will be key to having a solid fix in the library.

That doesn't necessarily mean you need to do the reduction on your own, but more information about what you discovered would be extremely helpful. For example, you said "It seems that Safari doesn't like further DOM manipulation to existing structure within this life cycle event" in your original report. Can you say more? What life cycle event? What DOM manipulation are you doing?

You mentioned a hidden text-field but I don't see one in the example code you supplied. Can you describe where you're putting the hidden text field? What element are you expecting to receive the keyboard events? Can you tell us which CodeMirror.net component you are using?

You reported this as a bug in Safari for Windows. Did you test it on Safari for OSX? If so, did you find that the bug was limited to Safari for Windows? Did you test it on Chrome for Windows, which uses the same rendering engine as Safari? If you haven't tested on Chrome for Windows, it would be very helpful if you could do so to help us narrow down the cause of the problem.

If you haven't tested it on Safari for OSX, it would be great if you could help us determine whether the bug is limited to Safari for Windows. Answering some of the above questions, like which lifecycle event you traced it down to and what CodeMirror.net component you are using could help us in our efforts to reproduce the bug.

It's not terribly related to the issue at hand, but note that in most cases Safari on Windows has fewer users than IE6. Also Apple has (apparently) ceased supporting it and Safari 6 does not ship on Windows. Given that, you may want to reconsider your CMS's support of it. Anyhow, this is a completely separate thing from the issue detailed above.

It goes without saying that Martin's insults against the jQuery team are completely rude and uncalled for. It's also a bit ironic when you consider reading through some of the bug reports on the Kentico Software forum. They ask for the specifics to reproduce bugs before they'll even look at it. I guess Martin was speaking more about Kentico than jQuery.

Replying to [comment:6 mikesherov]:

Replying to [comment:5 anonymous]: > Replying to [comment:3 mikesherov]: > > We are not sure whether it is a bug in "our own product" (which you are using for your own benefit, provided for free and lovingly maintained by us), which is why we asked for a simplified test case that reproduces this issue. > > > > If you're not willing to provide one to see that this is fixed, then we WILL wait until someone else reports it and spends the same hours as you did, and who is willing to work with us on resolving this issue instead of providing us with a vague, unactionable report. > > > > I said good day. > > No problem, your choice, though not at all motivational for us to report anything else in future. Also a good example of how ego makes open source projects not caring about the quality ... you should be very proud of yourself now ... Not about quality here. It's about how we can't take action without a test case that can reproduce this issue considering the overwhelming volume of bug reports we get, and work on, in our free time. Reports from people who are unwilling to work with us, and who tell us to fix bugs in our product despite not providing any actionable steps and take umbrage when repro steps are requested, are not reports we are going to act on. Simply, we will wait till someone can provide us actionable steps, as many people do. If there is a bug in jQuery here, someone will report it, and they'll be willing to provide repro steps. The way we do work here is create a failing unit test first, so the same regression doesn't happen in the future. Without repro steps, we can't create a test. You have asked us if your fix is "correct". We can't even begin to answer that question until we see how and why it's breaking in the first place. Yes, the fix may cause adverse side effects. Maybe not for you. But it won't be in jQuery core unless it can be proven how it's broken. If instead you are asking us if your fix would work for JUST you, then ask that in the forum. This is the bug tracker, where people are trying to fix issues in jQuery proper, and are expected to follow the bug reporting guidelines: "Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket."

The deal is I spent some volunteer time on it (if you like that saying that in every post) and I am not willing to spend more on an issue that is closed on me because I provided you with exact details about how to fix it. It is totally understandable that you have other priority things, I just think you are justifying this by the wrong means. I know it is hard to receive improvement feedback, just think sometimes about what you have written. I am not trash talking, I am just doing you favor by providing additional feedback. I have no problem to not do it if you insist you are being perfect in everything you do, the feedback serves mainly to receiver, not to sender.

Why I asked that? Because I expect that you know what the code you have written so you are more eligible to answer that question than me. This is about 10-15 lines of code that need to be examined by their author, nothing more. I am knowledgeable enough that I was able to track this to the depth of the code and fix this by myself, so I think the code author should be able to estimate the consequences of such change without the failing unit test.

How I know it is bug in your code and not our or CodeMirror? Simply because I was able to fix it by modifying your code. I didn't touch any other code and the issue was resolved. Yes, the main reason is probably a bug in the Safari itself but similar to "hacks" for other browsers, I see the need for similar "hack" here (even that this code update doesn't actually hack anything).

If you have unit tests (an I am sure that you have a unit test for this since this code is a very basis - detection of browser capabilities), it shouldn't be a problem for you to just do the changes I mentioned and verify whether it breaks something, it would actually take you less time than thinking about reasons why it can't be done. I would suggest you try to be more open minded and thing about ways how it could be done instead. (again, this is a feedback, not trash talking ...)

As I understand it now, you think it is better to keep the bug in there for 100% of future time than have it fixed and risk that it will reappear again and have it there for less time, maybe even not reappear. I understand your decision, I just don't think it is the right one for people using it. My opinion, you don't need to be angry about it.

I also understand that a bug report like this, though including details how to fix it isn't something you want (or can based on some of your internal rules) act upon, therefore I don't plan to report anything else in this matter unless I am willing to spend additional time to provide test case for it. Your product, your rules, I totally accept it ... just saying my opinion.

I still think you product is great, that is why I am trying to help you to improve it. I just expected other, more open-minded response, maybe something more grateful that I am trying to help, instead of you being angry that you are missing something I don't plan to provide (and I started by apologizing for that).

I am sorry that I spammed your bug tracker with improper report, I simply didn't notice that you require strict bug reporting guidelines and don't act upon reprot that don't exactly follow that. I wouldn't report it in the first place if I knew it.

Have a great day and if nothing else, take all what I have written as a feedback, not as a complaint ... I wasn't complaining at all.

Martin

Replying to [comment:7 dmethvin]:

There really isn't much we can do to fix the problem until we can reproduce it. It's pretty rare that someone outright refuses to provide a test case so that we can help them; color me stunned. A few copy-pasted lines isn't "all we need to fix it." Would this be something encountered by Kentico's customers or developers? Looks like there's a @kentico_devnet on Twitter, perhaps we can get their help if you're too busy.

It is something we encountered while developing our new version which uses updated CodeMirror components, that is one of the reasons why I can't provide you steps to reproduce it. As I said, I have no problem if you don't fix it, I was just trying to be helpful here with my available time which obviously wasn't received well.

Replying to [comment:12 anonymous]:

It goes without saying that Martin's insults against the jQuery team are completely rude and uncalled for. It's also a bit ironic when you consider reading through some of the bug reports on the Kentico Software forum. They ask for the specifics to reproduce bugs before they'll even look at it. I guess Martin was speaking more about Kentico than jQuery.

I don't think I was insulting anyone (was I, can you be more specific?), if I was, I am sorry, that wasn't my intention. I was just telling my honest opinion about their responses and reasons why they don't plan to act about it (which in fact were very rude and emotional), to give them feedback. I know honesty isn't received very well on internet forums but I don't mind arguing with someone publicly if I stand behind my opinions.

About our forums: Yes, we kindly ask for steps to reproduce and this is absolutely normal, but even in cases where client doesn't know or doesn't want to spend more time on it, we spend our time to try to reproduce and check our code to see if some potential problem may be there, or use their fix if it doesn't break other functionality. That is the main difference.

I apologized for not spending more time on that because it already took a lot of my time, and the response for it was very angry, you simply cannot force people to do something for you if they are not willing to do that. Do you understand that?

They could simply say that they have other priorities and not enough time to solve issue they cannot reproduce and it would be absolutely valid. Instead they just provided angry reponses with a lot of other reasons that I think aren't the right ones so I said it out loud.

Now you are responding the same way you are criticizing, trying to insult me. That seems OK to you?

Martin

Replying to [comment:11 paul.irish]:

It's not terribly related to the issue at hand, but note that in most cases Safari on Windows has fewer users than IE6. Also Apple has (apparently) ceased supporting it and Safari 6 does not ship on Windows. Given that, you may want to reconsider your CMS's support of it. Anyhow, this is a completely separate thing from the issue detailed above.

Hi, we support Safari for Mac, just use Safari for Windows as a primary testing platform (we simply don't have enough Macs here to run full tests so we verify only fixed issues on Mac and run last round of test suites on it). We use Safari for WIndows because in our whole history we experienced the same behavior with both of them no matter what the issue was. I just mentioned that to be precise enough in bug report.

I noticed that I didn't answer one of the previously asked questions. We didn't experience the same behavior with Chrome, it is using the same rendering engine but this seems to be more about how they handle components and events which seems to be different in both.

Martin, thanks for the thoughtful response. Perhaps I took your initial reluctance to provide repro steps too harshly. My apologies. I sometimes forget that not everyone immediately understands how our bug reporting process goes. I'd like to further respond to each of your points, but I think we've both honestly spent too much time here already, and I'd rather just let this settle. If you'd really like this discussion to continue, we can chat in the #jquery irc channel on freenode.

Just to close the loop here on this issue, the line of code changed in the changes you provided have since been changed in jQuery 1.8 to address an issue with CSP. Perhaps you can test your code against 1.8 to see if CSP was the root cause.

If not, I can not move forward with your proposed patch, as it would break a known, reproducible behavior. If you'd like to reconsider your position on providing a test case, so I can fix the bug, we can move forward with this issue.

Replying to [comment:18 mikesherov]:

Just to close the loop here on this issue, the line of code changed in the changes you provided have since been changed in jQuery 1.8 to address an issue with CSP. Perhaps you can test your code against 1.8 to see if CSP was the root cause. If not, I can not move forward with your proposed patch, as it would break a known, reproducible behavior. If you'd like to reconsider your position on providing a test case, so I can fix the bug, we can move forward with this issue.

Hi, thank you for the information, this is helpful.

No need to apologize. I didn't take any of that personally, I just wanted to solve the case. These things happen, each of us had different expectations, it just sometimes needs some more time to figure that out. I am glad we did that. If we have a chance to meet sometimes in future, I will be glad to shake your hand and have a beer with you.

I am just sorry that other people had to took part in this conversation. I thought that making that report personal instead of just anonymous could help the case to let you know that I am not just some student, but someone behind a more complex product that you could trust with the details.

Unfortunately, we can't test it right now with version 1.8 because we are too close with the deadlines for the release of our new version which makes us all too busy. I will try to find some time after we release it to give you some more details about this, and also let you know whether newer version is OK. Until then, just let this be and keep focusing on higher priorities.

Thanks for your time!

Martin