Bugs :
K-Meleon Web Browser Forum
G'day mikeyww -
The problem W3C Validator had with this page is the same problem KM76 has. It is more than "just" the <noscript> block, although removing that allowed the full validation.
The <noscript> was actually referencing a script... It would never work regardless of which browser you had. And in fact it was not responsible for K-M's crash. The main K-M problem in this instance was that ESR38 precompiles the JS as a time-saver for later. So when K-M saw a <noscript> which referenced a script, and of course in going to get the facebook page it saw a <head> and a <body>, so it got very confused.
I'm working this out after the event, and it took me a while to figure that if the offending bits were not in OspreyPack, then they had to be in FaceBook.
Bear in mind that the second line of the page is itself a serious but not fatal error: <html> does not take a "class" attribute. The fourth line is also a serious non-fatal error: the "X-UA-Compatible" attribute takes only one datum, almost always "IE=edge". It does not take a list.
Then we have the XML fatal: the double hyphen breaks the XML evaluation: "TODO -- Generate..." The validator saw this even in the middle of a comment. I had to use Pale Moon to get the source code, and even PM had a problem with this line, I can tell because it printed the entire comment in red.
EDIT: rm dribble :END EDIT
I have noticed that with judicious use of UA strings (and K-M has the easiest system around) there are very few sites that won't render in K-M, and blindingly fast at that. Here's my favourite: Browser sniffing is dead. Move on. The nature of Son Gokū is... Irrepressible!!!!
____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]
Edited 1 time(s). Last edit at 07/30/2016 09:44AM by gordon451.
Now it is getting tiresome and nerving.
This forum is not a platform for ranting ignorants!
An img element can't be inside a head element. Told by the validator.
Do you guess why yours passes?
Why should be explained by me?
First, I'm not a master at html, so is my guess. I should read all the standard, what I'm not going to do.
When the img element is added to a noscript in the head, probably this makes a browser to understand that the body has started, and therefore, a closing head, is not allowed.
Browsers do their best, and even if it is not allowed they will render, and render an element inside a head, but make it visible, implies to create a body to make it well placed.
Again, is my guess. Ask W3 Consortium, not me.
About the bold text, are you kidding? Do you really think that a lot of software out there are clean of bugs? Do you understand why software licenses tell users that are not responsible for what their software can do in a statement like "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND"?
Because programmers are humans and errors happen as bugs. As simple as that. How could Dorian imagine that Mozilla included a regression in Gecko 38 that caused a buffer overflow or crash with javascript, css or whatever? And if Mozilla has a fix that didn't include it yet, what could be done?
Do you know how many lines of code are in Gecko? Even if hard for Mozilla to audit, imagine one person.
Chrome as alternative? Go to Chrome Google forums and read about broken renderings too.
Now? It started when was already said that the same Gecko version has the same issues. Re-suggested by Siria, after confirmed by rodocop.
Edited 1 time(s). Last edit at 07/30/2016 03:33PM by JohnHell.
Thank you for the replies and explanations. Sorry that I am so ignorant. I know that coding is hardly ever perfect, and Gecko is beyond local control here. I applaud everyone's efforts. My only hope is that we will not shrug our shoulders in the face of fatal crashes. I wish I had a good suggestion for specifically what to do about this one, but alas, I am not that smart!
Best wishes --
Mike
Claiming a browser (and its developer) being "unethical" just because it's not perfect and contains bugs that may crash occasionally, putting it as if every ethical person would of course think the same, and then wanting KM to be completely reprogrammed and based on Chrome instead, which obviously must be completely bugfree then or it wouldn't be "ethical" either - that was so far out-of-world that my first thought actually was: I don't believe this... could it be that KM's userbase now has reached relevant numbers and the big competitions are starting actions to discredit it??? LOL!
Your points are well taken. I thought I might inspire some action about the bug, but it looks like I've been defeated! I suppose that I will simply need a different browser if I decide to buy an Osprey backpack. I know that none of the browsers are perfect, so I should be content with one that works most of the time. I guess I should stop writing so as not to irritate the group that is working to improve the product. Thanks again for this interesting browser.
Mike
Mike, is not about ignorance. Yogi, in my opinion was rude there, but you have been stick like glue that this should be fixed in K-meleon, when, one way or another, has been told this is not a K-meleon bug.
What happens when someone reports something as a bug, is that the older members here, or with more knowledge, or just with energy to help, try to investigate the bug to confirm, or "reject" it so we can make developer life easier. If the bug is confirmed, less work for Dorian and Hermes. If we find it is not a bug, less work for them.
Maybe haven't been used the best words to explain it, assuming knowledge, but, from the first reply from rodocop, was said that this is not a K-meleon bug, but the engine bug and there is not control from K-meleon, or, better said, from the only one/two developer(s) actually improving K-meleon.
What happens with Gecko is that it is an engine, and then there are shells, as Seamonkey, Firefox, K-meleon, Palemoon, etc. As other browsers like Chromium, where this is the engine, and then comes Chrome, Opera, etc, etc.
Graphically.
Also, we told you that sites with malformed content, and that page wasn't a bad example, can crash browsers. Even now wasn't strictly a page bug, but, maybe, a regression in the Gecko version.
Then you stick on W3 code validation that the page was fine, and again, it wasn't fine.
In the end, one way or another, believe it or not, making youself victim, or not, this started to be annoying.
And you are right, you were trying to inspire some action, but also we explained that there weren't any action we could take.
I hope that now you can undertand what happens and what happened here.
You don't need to stop talking or leave the forum.
I undertand, anyway, if you want to.
JohnHell, you have explained that so well, and I thank you. You are completely right. My frustration was simply that I have tried the Osprey site in every other current version of major browsers, and K-Meleon's current version is the only one that fails!
This seemed rather unusual to me, but folks here pointed out that KM is using a specific version or type of Gecko, perhaps not the same one used by some other browsers. I see from the various replies that KM developers cannot address the issue with the Gecko version that they are using, and they cannot control this. Presumably, too, they cannot update or change their Gecko version, or there is good reason not to do so. I know that, quite possibly (and likely), there are other Web sites where other browsers would fail, and KM would succeed. In any case, I guess it will all improve when the adopted Gecko type is updated by Gecko developers and then by KM in the future.
Thanks again.
Mike
Edited 7 time(s). Last edit at 08/03/2016 12:25AM by mikeyww.
You can talk about issues with k-meleon here.
Re: Quick crash
Posted by:
gordon451
Date: July 30, 2016 08:50AM
G'day mikeyww -
The problem W3C Validator had with this page is the same problem KM76 has. It is more than "just" the <noscript> block, although removing that allowed the full validation.
The <noscript> was actually referencing a script... It would never work regardless of which browser you had. And in fact it was not responsible for K-M's crash. The main K-M problem in this instance was that ESR38 precompiles the JS as a time-saver for later. So when K-M saw a <noscript> which referenced a script, and of course in going to get the facebook page it saw a <head> and a <body>, so it got very confused.
I'm working this out after the event, and it took me a while to figure that if the offending bits were not in OspreyPack, then they had to be in FaceBook.
Bear in mind that the second line of the page is itself a serious but not fatal error: <html> does not take a "class" attribute. The fourth line is also a serious non-fatal error: the "X-UA-Compatible" attribute takes only one datum, almost always "IE=edge". It does not take a list.
Then we have the XML fatal: the double hyphen breaks the XML evaluation: "TODO -- Generate..." The validator saw this even in the middle of a comment. I had to use Pale Moon to get the source code, and even PM had a problem with this line, I can tell because it printed the entire comment in red.
EDIT: rm dribble :END EDIT
Quote
mikeyww
Here is my example page. The code is not perfect but works perfectly in KM.
That seems to be the image you posted in your second post. I don't understand your question.
What is the error that you are highlighting?
EDIT: Not sure. I dribbled a bit above. My opinion is the src adrress was the prime cause of disaster. Sanity returned when I deleted the <img> because it must absolutely have a src attribute. END EDIT
You have also not explained why the validator's two statements are valid.
Again, explained above. It's a lot like telling somebody to insert a completely different recipe into the middle of the one the person is already using, and to do exactly what the new recipe says.
I think, too, that KM developers need a more user-centered approach to accountability regarding their "packaged product". No ethical company would knowingly and intentionally distribute a product containing a faulty component made by another company, right? Why would KM's expert developers do this? Just because they are volunteers? All the more reason to select a better engine. If the current engine doesn't work well, find a better one (I suggest; Chrome's, perhaps?)! Alternatively, if the old engine works more reliably than the new one, then use the old one. Whatever, but while pointing the finger may identify the problem, it does not identify the solution.
I've addressed this in my first and third posts. I must confess I used to have the old Presto-engined Opera as my main browser, before they decided to go over to the Chrome-Blink engine which I dislike completely. I have always liked the Gecko engine, but it was badly let down by Mozilla's attitude with the chrome. KM gives me the best of both worlds. I still keep other browsers simply to render pages that break other browsers. My employer has one such infra-web site which AFAIK works only in IE. Possibly also in Safari :s
Ethical company? Microsoft perhaps? Did you ever use Nescape Navigator aka Netscape 4? NCSA Mosaic, which could not understand NetBIOS or NetBEUI?
Find a better one? Blink (I think that's the latest)? Edge? ESR >38? Is there an engine with no known or predicted problems?
Mike
I have noticed that with judicious use of UA strings (and K-M has the easiest system around) there are very few sites that won't render in K-M, and blindingly fast at that. Here's my favourite: Browser sniffing is dead. Move on. The nature of Son Gokū is... Irrepressible!!!!
____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]
Edited 1 time(s). Last edit at 07/30/2016 09:44AM by gordon451.
Re: Quick crash
Posted by:
Yogi
Date: July 30, 2016 10:40AM
Now it is getting tiresome and nerving.
Quote
mikeyww
I think, too, that KM developers need a more user-centered approach to accountability regarding their "packaged product". No ethical company would knowingly and intentionally distribute a product containing a faulty component made by another company, right? Why would KM's expert developers do this? Just because they are volunteers? All the more reason to select a better engine. If the current engine doesn't work well, find a better one (I suggest; Chrome's, perhaps?)! Alternatively, if the old engine works more reliably than the new one, then use the old one. Whatever, but while pointing the finger may identify the problem, it does not identify the solution.
Mike
This forum is not a platform for ranting ignorants!
Re: Quick crash
Posted by:
JohnHell
Date: July 30, 2016 03:31PM
Quote
mikeyww
Here is my example page. The code is not perfect but works perfectly in KM.
What is the error that you are highlighting?
An img element can't be inside a head element. Told by the validator.
Do you guess why yours passes?
Quote
mikeyww
You have also not explained why the validator's two statements are valid.
Why should be explained by me?
First, I'm not a master at html, so is my guess. I should read all the standard, what I'm not going to do.
When the img element is added to a noscript in the head, probably this makes a browser to understand that the body has started, and therefore, a closing head, is not allowed.
Browsers do their best, and even if it is not allowed they will render, and render an element inside a head, but make it visible, implies to create a body to make it well placed.
Again, is my guess. Ask W3 Consortium, not me.
Quote
mikeyww
I think, too, that KM developers need a more user-centered approach to accountability regarding their "packaged product". No ethical company would knowingly and intentionally distribute a product containing a faulty component made by another company, right? Why would KM's expert developers do this? Just because they are volunteers? All the more reason to select a better engine. If the current engine doesn't work well, find a better one (I suggest; Chrome's, perhaps?)! Alternatively, if the old engine works more reliably than the new one, then use the old one. Whatever, but while pointing the finger may identify the problem, it does not identify the solution.
Mike
About the bold text, are you kidding? Do you really think that a lot of software out there are clean of bugs? Do you understand why software licenses tell users that are not responsible for what their software can do in a statement like "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND"?
Because programmers are humans and errors happen as bugs. As simple as that. How could Dorian imagine that Mozilla included a regression in Gecko 38 that caused a buffer overflow or crash with javascript, css or whatever? And if Mozilla has a fix that didn't include it yet, what could be done?
Do you know how many lines of code are in Gecko? Even if hard for Mozilla to audit, imagine one person.
Chrome as alternative? Go to Chrome Google forums and read about broken renderings too.
Quote
Yogi
Now it is getting tiresome and nerving.
Now? It started when was already said that the same Gecko version has the same issues. Re-suggested by Siria, after confirmed by rodocop.
Edited 1 time(s). Last edit at 07/30/2016 03:33PM by JohnHell.
Re: Quick crash
Posted by:
mikeyww
Date: July 30, 2016 06:51PM
Thank you for the replies and explanations. Sorry that I am so ignorant. I know that coding is hardly ever perfect, and Gecko is beyond local control here. I applaud everyone's efforts. My only hope is that we will not shrug our shoulders in the face of fatal crashes. I wish I had a good suggestion for specifically what to do about this one, but alas, I am not that smart!
Best wishes --
Mike
Re: Quick crash
Posted by:
siria
Date: July 30, 2016 09:22PM
Quote
mikeyww
No ethical company would knowingly and intentionally distribute a product containing a faulty component made by another company, right? (...) If the current engine doesn't work well, find a better one (I suggest; Chrome's, perhaps?)!
Claiming a browser (and its developer) being "unethical" just because it's not perfect and contains bugs that may crash occasionally, putting it as if every ethical person would of course think the same, and then wanting KM to be completely reprogrammed and based on Chrome instead, which obviously must be completely bugfree then or it wouldn't be "ethical" either - that was so far out-of-world that my first thought actually was: I don't believe this... could it be that KM's userbase now has reached relevant numbers and the big competitions are starting actions to discredit it??? LOL!
Fine. KM75 is still around for download. So no prob to use the old oneQuote
mikeyww
Alternatively, if the old engine works more reliably than the new one, then use the old one.
Re: Quick crash
Posted by:
mikeyww
Date: July 30, 2016 10:18PM
Your points are well taken. I thought I might inspire some action about the bug, but it looks like I've been defeated! I suppose that I will simply need a different browser if I decide to buy an Osprey backpack. I know that none of the browsers are perfect, so I should be content with one that works most of the time. I guess I should stop writing so as not to irritate the group that is working to improve the product. Thanks again for this interesting browser.
Mike
Re: Quick crash
Posted by:
JohnHell
Date: August 01, 2016 03:19PM
Mike, is not about ignorance. Yogi, in my opinion was rude there, but you have been stick like glue that this should be fixed in K-meleon, when, one way or another, has been told this is not a K-meleon bug.
What happens when someone reports something as a bug, is that the older members here, or with more knowledge, or just with energy to help, try to investigate the bug to confirm, or "reject" it so we can make developer life easier. If the bug is confirmed, less work for Dorian and Hermes. If we find it is not a bug, less work for them.
Maybe haven't been used the best words to explain it, assuming knowledge, but, from the first reply from rodocop, was said that this is not a K-meleon bug, but the engine bug and there is not control from K-meleon, or, better said, from the only one/two developer(s) actually improving K-meleon.
What happens with Gecko is that it is an engine, and then there are shells, as Seamonkey, Firefox, K-meleon, Palemoon, etc. As other browsers like Chromium, where this is the engine, and then comes Chrome, Opera, etc, etc.
Graphically.
Gecko | | ↓¯¯¯¯¯¯¯¯¯↓¯¯¯¯¯¯¯¯¯↓¯¯¯¯¯¯¯¯¯↓¯¯¯¯¯¯¯¯¯↓ Seamonkey Firefox K-meleon Palemoon Others
Also, we told you that sites with malformed content, and that page wasn't a bad example, can crash browsers. Even now wasn't strictly a page bug, but, maybe, a regression in the Gecko version.
Then you stick on W3 code validation that the page was fine, and again, it wasn't fine.
In the end, one way or another, believe it or not, making youself victim, or not, this started to be annoying.
And you are right, you were trying to inspire some action, but also we explained that there weren't any action we could take.
I hope that now you can undertand what happens and what happened here.
You don't need to stop talking or leave the forum.
I undertand, anyway, if you want to.
Re: Quick crash
Posted by:
mikeyww
Date: August 02, 2016 09:05AM
JohnHell, you have explained that so well, and I thank you. You are completely right. My frustration was simply that I have tried the Osprey site in every other current version of major browsers, and K-Meleon's current version is the only one that fails!
- SeaMonkey 2.40: works
- Pale Moon 26.3.3: works
- Firefox 47.0.1: works
This seemed rather unusual to me, but folks here pointed out that KM is using a specific version or type of Gecko, perhaps not the same one used by some other browsers. I see from the various replies that KM developers cannot address the issue with the Gecko version that they are using, and they cannot control this. Presumably, too, they cannot update or change their Gecko version, or there is good reason not to do so. I know that, quite possibly (and likely), there are other Web sites where other browsers would fail, and KM would succeed. In any case, I guess it will all improve when the adopted Gecko type is updated by Gecko developers and then by KM in the future.
Thanks again.
Mike
Edited 7 time(s). Last edit at 08/03/2016 12:25AM by mikeyww.
English