{"thread":{"id":"21672","subject":"[PATCH 0/2] jn/gitweb-blame fixes","startedAt":"2009-11-19T19:44:45Z","lastAt":"2009-12-09T00:08:58Z","messageCount":41,"participants":["Stephen Boyd","Jakub Narebski","Nanako Shiraishi","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"127921","messageId":"1258659887-5244-1-git-send-email-bebarino@gmail.com","threadId":"21672","inReplyTo":null,"subject":"[PATCH 0/2] jn/gitweb-blame fixes","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-19T19:44:45Z","receivedAt":"2009-11-19T19:44:45Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"This series is based on next's jn/gitweb-blame branch.\n\nI was trying out the incremental blame and noticed it didn't work each \ntime. The first patch fixes the crashing I experience when blaming\ngitweb.perl (ironic ;-)\n\nThe second patch fixes a visible bug I see in Firefox. Although I assume\non other browsers it's not a problem? I haven't tested it on others so I\ncan't be sure.\n\nStephen Boyd (2):\n gitweb.js: fix null object exception in initials calculation\n gitweb.js: use unicode encoding for nbsp instead of html entity\n\n gitweb/gitweb.js | 15 +++++++++------\n 1 files changed, 9 insertions(+), 6 deletions(-)\n"},{"id":"127922","messageId":"1258659887-5244-2-git-send-email-bebarino@gmail.com","threadId":"21672","inReplyTo":"1258659887-5244-1-git-send-email-bebarino@gmail.com","subject":"[PATCH 1/2] gitweb.js: fix null object exception in initials calculation","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-19T19:44:46Z","receivedAt":"2009-11-19T19:44:46Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Currently handleLine() assumes that a commit author name will always\nstart with a capital letter. It's possible that the author name is\nuser@example.com and therefore calling a match() on the name will fail\nto return any matches. Subsequently joining these matches will cause an\nexception. Fix by checking that we have a match before trying to join\nthe results into a set of initials for the author.\n\nSigned-off-by: Stephen Boyd \n---\n gitweb/gitweb.js | 7 +++++--\n 1 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/gitweb/gitweb.js b/gitweb/gitweb.js\nindex 22570f5..02454d8 100644\n--- a/gitweb/gitweb.js\n+++ b/gitweb/gitweb.js\n@@ -532,8 +532,11 @@ function handleLine(commit, group) {\n \t\t\tif (group.numlines >= 2) {\n \t\t\t\tvar fragment = document.createDocumentFragment();\n \t\t\t\tvar br = document.createElement(\"br\");\n-\t\t\t\tvar text = document.createTextNode(\n-\t\t\t\t\tcommit.author.match(/\\b([A-Z])\\B/g).join(''));\n+\t\t\t\tvar match = commit.author.match(/\\b([A-Z])\\B/g);\n+\t\t\t\tif (match) {\n+\t\t\t\t\tvar text = document.createTextNode(\n+\t\t\t\t\t\t\tmatch.join(''));\n+\t\t\t\t}\n \t\t\t\tif (br && text) {\n \t\t\t\t\tvar elem = fragment || td_sha1;\n \t\t\t\t\telem.appendChild(br);\n-- \n1.6.5.3.433.g11067\n"},{"id":"127923","messageId":"1258659887-5244-3-git-send-email-bebarino@gmail.com","threadId":"21672","inReplyTo":"1258659887-5244-1-git-send-email-bebarino@gmail.com","subject":"[PATCH 2/2] gitweb.js: use unicode encoding for nbsp instead of html entity","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-19T19:44:47Z","receivedAt":"2009-11-19T19:44:47Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"It seems that in Firefox-3.5 inserting nbsp with javascript inserts the\nliteral nbsp; instead of a space. Fix this by inserting the unicode\nrepresentation for nbsp instead.\n\nSigned-off-by: Stephen Boyd \n---\n gitweb/gitweb.js | 8 ++++----\n 1 files changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/gitweb/gitweb.js b/gitweb/gitweb.js\nindex 02454d8..30597dd 100644\n--- a/gitweb/gitweb.js\n+++ b/gitweb/gitweb.js\n@@ -31,12 +31,12 @@\n \n /**\n * pad number N with nonbreakable spaces on the left, to WIDTH characters\n- * example: padLeftStr(12, 3, ' ') == ' 12'\n- * (' ' is nonbreakable space)\n+ * example: padLeftStr(12, 3, '\\u00A0') == '\\u00A012'\n+ * ('\\u00A0' is nonbreakable space)\n *\n * @param {Number|String} input: number to pad\n * @param {Number} width: visible width of output\n- * @param {String} str: string to prefix to string, e.g. ' '\n+ * @param {String} str: string to prefix to string, e.g. '\\u00A0'\n * @returns {String} INPUT prefixed with (WIDTH - INPUT.length) x STR\n */\n function padLeftStr(input, width, str) {\n@@ -158,7 +158,7 @@ function updateProgressInfo() {\n \n \tif (div_progress_info) {\n \t\tdiv_progress_info.firstChild.data = blamedLines + ' / ' + totalLines +\n-\t\t\t' (' + padLeftStr(percentage, 3, ' ') + '%)';\n+\t\t\t' (' + padLeftStr(percentage, 3, '\\u00A0') + '%)';\n \t}\n \n \tif (div_progress_bar) {\n-- \n1.6.5.3.433.g11067\n"},{"id":"127932","messageId":"200911192240.27743.jnareb@gmail.com","threadId":"21672","inReplyTo":"1258659887-5244-2-git-send-email-bebarino@gmail.com","subject":"Re: [PATCH 1/2] gitweb.js: fix null object exception in initials calculation","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-19T21:40:26Z","receivedAt":"2009-11-19T21:40:26Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 19 Nov 2009, Stephen Boyd wrote:\n\n> Currently handleLine() assumes that a commit author name will always\n> start with a capital letter. It's possible that the author name is\n> user@example.com and therefore calling a match() on the name will fail\n> to return any matches. Subsequently joining these matches will cause an\n> exception. Fix by checking that we have a match before trying to join\n> the results into a set of initials for the author.\n> \n> Signed-off-by: Stephen Boyd \n\nAcked-by: Jakub Narebski \n\n> ---\n\n[From \"[PATCH 0/2] jn/gitweb-blame fixes\"]\n> This series is based on next's jn/gitweb-blame branch.\n>\n> I was trying out the incremental blame and noticed it didn't work\n> each time. The first patch fixes the crashing I experience when\n> blaming gitweb.perl (ironic ;-)\n\nHmmm... gitweb/gitweb.perl *was* one of files I have tested \n'blame_incremental' view on, but I have not experienced any\ncrashes.\n\nPerhaps it was the matter of different JavaScript engine (Mozilla 1.7.12\nwith Gecko/20050923 engine, Konqueror 3.5.3-0.2.fc4), or different\nstarting point for blame.\n\nI assume that crashing lead simply to not working blame, not to browser\ncrash?\n\n> gitweb/gitweb.js | 7 +++++--\n> 1 files changed, 5 insertions(+), 2 deletions(-)\n> \n> diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js\n> index 22570f5..02454d8 100644\n> --- a/gitweb/gitweb.js\n> +++ b/gitweb/gitweb.js\n> @@ -532,8 +532,11 @@ function handleLine(commit, group) {\n> \t\t\tif (group.numlines >= 2) {\n> \t\t\t\tvar fragment = document.createDocumentFragment();\n> \t\t\t\tvar br = document.createElement(\"br\");\n> -\t\t\t\tvar text = document.createTextNode(\n> -\t\t\t\t\tcommit.author.match(/\\b([A-Z])\\B/g).join(''));\n> +\t\t\t\tvar match = commit.author.match(/\\b([A-Z])\\B/g);\n> +\t\t\t\tif (match) {\n> +\t\t\t\t\tvar text = document.createTextNode(\n> +\t\t\t\t\t\t\tmatch.join(''));\n> +\t\t\t\t}\n> \t\t\t\tif (br && text) {\n> \t\t\t\t\tvar elem = fragment || td_sha1;\n> \t\t\t\t\telem.appendChild(br);\n\nThanks. It now corresponds to what it is done for ordinary 'blame'\nview, i.e.:\n\n\tmy @author_initials = ($author =~ /\\b([[:upper:]])\\B/g);\n\tif (@author_initials) {\n\t\tprint \"
\" .\n\t\t esc_html(join('', @author_initials));\n\t\t# or join('.', ...)\n\t}\n\n\nP.S. Unfortunately unless we decide to generate JavaScript from Perl code,\nusing something like GWT for Java or Pylons for Python, e.g. CGI::Ajax\n(which is not in Perl core), we would have to have such code duplication.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"127938","messageId":"780e0a6b0911191448p4c0f5e97j2c2a4cdc0ad9193d@mail.gmail.com","threadId":"21672","inReplyTo":"200911192240.27743.jnareb@gmail.com","subject":"Re: [PATCH 1/2] gitweb.js: fix null object exception in initials calculation","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-19T22:48:50Z","receivedAt":"2009-11-19T22:48:50Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"2009/11/19 Jakub Narebski :\n>\n> Hmmm... gitweb/gitweb.perl *was* one of files I have tested\n> 'blame_incremental' view on, but I have not experienced any\n> crashes.\n>\n> Perhaps it was the matter of different JavaScript engine (Mozilla 1.7.12\n> with Gecko/20050923 engine, Konqueror 3.5.3-0.2.fc4), or different\n> starting point for blame.\n>\n> I assume that crashing lead simply to not working blame, not to browser\n> crash?\n\nYes. The blame stops at 20% or something but the browser is fine.\n"},{"id":"129238","messageId":"200911200000.41658.jnareb@gmail.com","threadId":"21672","inReplyTo":"1258659887-5244-3-git-send-email-bebarino@gmail.com","subject":"Re: [PATCH 2/2] gitweb.js: use unicode encoding for nbsp instead of html entity","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-19T23:00:40Z","receivedAt":"2009-11-19T23:00:40Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 19 Nov 2009, Stephen Boyd wrote:\n\n> It seems that in Firefox-3.5 inserting nbsp with javascript inserts the\n> literal nbsp; instead of a space. Fix this by inserting the unicode\n> representation for nbsp instead.\n\nErrr... why are you avoiding writing   or \" \" here?\n\n> \n> Signed-off-by: Stephen Boyd \n> ---\n\n[From \"[PATCH 0/2] jn/gitweb-blame fixes\"]\n> This series is based on next's jn/gitweb-blame branch.\n\n> The second patch fixes a visible bug I see in Firefox. Although I\n> assume on other browsers it's not a problem? I haven't tested it on\n> others so I can't be sure.\n\nWell, since I moved from elem.innerHTML (which is non-standard, and\ndoes not work for some browsers in strict XHTML mode) to setting\nelem.firstChild.data (which assumes that firstChild exists and it\nis a text node) I have had damned *intermittent* bugs where sometimes\n' ' would be shown literally, and sometimes this entity would\nbe correctly rendered.\n\nI suspect this is either bug in Firefox, or unspecified part of DOM.\n\nAs we need this only for progress report, I am not against this change,\nif it doesn't make it worse in other browsers.\n\n> gitweb/gitweb.js | 8 ++++----\n> 1 files changed, 4 insertions(+), 4 deletions(-)\n> \n> diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js\n> index 02454d8..30597dd 100644\n> --- a/gitweb/gitweb.js\n> +++ b/gitweb/gitweb.js\n> @@ -31,12 +31,12 @@\n> \n> /**\n> * pad number N with nonbreakable spaces on the left, to WIDTH characters\n> - * example: padLeftStr(12, 3, ' ') == ' 12'\n> - * (' ' is nonbreakable space)\n> + * example: padLeftStr(12, 3, '\\u00A0') == '\\u00A012'\n> + * ('\\u00A0' is nonbreakable space)\n> *\n> * @param {Number|String} input: number to pad\n> * @param {Number} width: visible width of output\n> - * @param {String} str: string to prefix to string, e.g. ' '\n> + * @param {String} str: string to prefix to string, e.g. '\\u00A0'\n> * @returns {String} INPUT prefixed with (WIDTH - INPUT.length) x STR\n> */\n> function padLeftStr(input, width, str) {\n> @@ -158,7 +158,7 @@ function updateProgressInfo() {\n> \n> \tif (div_progress_info) {\n> \t\tdiv_progress_info.firstChild.data = blamedLines + ' / ' + totalLines +\n> -\t\t\t' (' + padLeftStr(percentage, 3, ' ') + '%)';\n> +\t\t\t' (' + padLeftStr(percentage, 3, '\\u00A0') + '%)';\n> \t}\n> \n> \tif (div_progress_bar) {\n> -- \n> 1.6.5.3.433.g11067\n> \n> \n\n-- \nJakub Narebski\nPoland\n"},{"id":"127939","messageId":"200911200005.08841.jnareb@gmail.com","threadId":"21672","inReplyTo":"1258659887-5244-1-git-send-email-bebarino@gmail.com","subject":"Re: [PATCH 0/2] jn/gitweb-blame fixes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-19T23:05:08Z","receivedAt":"2009-11-19T23:05:08Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 19 Nov 2009, Stephen Boyd wrote:\n\n> This series is based on next's jn/gitweb-blame branch.\n> \n> I was trying out the incremental blame and noticed it didn't work each \n> time. The first patch fixes the crashing I experience when blaming\n> gitweb.perl (ironic ;-)\n> \n> The second patch fixes a visible bug I see in Firefox. Although I assume\n> on other browsers it's not a problem? I haven't tested it on others so I\n> can't be sure.\n\nThanks for working on this. Also it is nice to have incremental blame\ntested for another browser, beside Mozilla 1.17.2 and Konqueror 3.5.3\n\n-- \nJakub Narebski\nPoland\n"},{"id":"127945","messageId":"4B05EA20.1080706@gmail.com","threadId":"21672","inReplyTo":"200911200000.41658.jnareb@gmail.com","subject":"Re: [PATCH 2/2] gitweb.js: use unicode encoding for nbsp instead of html entity","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-20T01:00:16Z","receivedAt":"2009-11-20T01:00:16Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Jakub Narebski wrote:\n> On Thu, 19 Nov 2009, Stephen Boyd wrote\n>> It seems that in Firefox-3.5 inserting nbsp with javascript inserts the\n>> literal nbsp; instead of a space. Fix this by inserting the unicode\n>> representation for nbsp instead.\n>\n> Errr... why are you avoiding writing   or \" \" here?\n\nSorry, this part was rushed out. I can fix it in a resend if this is \nactually the right thing to do.\n\n> Well, since I moved from elem.innerHTML (which is non-standard, and\n> does not work for some browsers in strict XHTML mode) to setting\n> elem.firstChild.data (which assumes that firstChild exists and it\n> is a text node) I have had damned *intermittent* bugs where sometimes\n> ' ' would be shown literally, and sometimes this entity would\n> be correctly rendered.\n>\n> I suspect this is either bug in Firefox, or unspecified part of DOM.\n>\n> As we need this only for progress report, I am not against this change,\n> if it doesn't make it worse in other browsers.\n\nI've tested this in Opera-10.10 now and it looks good. I'll try to get \nmy hands on a Windows machine to test with IE, but no promises.\n"},{"id":"127946","messageId":"4B05EA37.7060704@gmail.com","threadId":"21672","inReplyTo":"200911200005.08841.jnareb@gmail.com","subject":"Re: [PATCH 0/2] jn/gitweb-blame fixes","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-20T01:00:39Z","receivedAt":"2009-11-20T01:00:39Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Jakub Narebski wrote:\n>\n> Thanks for working on this. Also it is nice to have incremental blame\n> tested for another browser, beside Mozilla 1.17.2 and Konqueror 3.5.3\n\nFor those following along, Opera-10.10 has been tested and works.\n"},{"id":"127973","messageId":"4B06157B.10203@gmail.com","threadId":"21672","inReplyTo":"4B05EA37.7060704@gmail.com","subject":"Re: [PATCH 0/2] jn/gitweb-blame fixes","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-20T04:05:15Z","receivedAt":"2009-11-20T04:05:15Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Stephen Boyd wrote:\n> Jakub Narebski wrote:\n>>\n>> Thanks for working on this. Also it is nice to have incremental blame\n>> tested for another browser, beside Mozilla 1.17.2 and Konqueror 3.5.3\n>\n> For those following along, Opera-10.10 has been tested and works.\n\nOk. I tried using the version of incremental blame that's in next \n(e206d62 gitweb: Colorize 'blame_incremental' view during processing, \n2009-09-01) on IE8 with no success. The page loads and the file is shown \nwith line numbers, but the progress is stuck at 0% (with the   \nshowing too).\n\nI then tried with my two patches applied on top of e206d62 on IE8 and \nstill no success. The page loads and the file is show with the line \nnumbers but still stuck at 0%, but the   is gone at least.\n\nDo you have access to IE8 to confirm?\n"},{"id":"128058","messageId":"200911210132.44649.jnareb@gmail.com","threadId":"21672","inReplyTo":"4B06157B.10203@gmail.com","subject":"Re: [PATCH 0/2] jn/gitweb-blame fixes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-21T00:32:42Z","receivedAt":"2009-11-21T00:32:42Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 20 Nov 2009, Stephen Boyd wrote:\n> Stephen Boyd wrote:\n> > Jakub Narebski wrote:\n> > >\n> > > Thanks for working on this. Also it is nice to have incremental blame\n> > > tested for another browser, beside Mozilla 1.17.2 and Konqueror 3.5.3\n> >\n> > For those following along, Opera-10.10 has been tested and works.\n> \n> Ok. I tried using the version of incremental blame that's in next \n> (e206d62 gitweb: Colorize 'blame_incremental' view during processing, \n> 2009-09-01) on IE8 with no success. The page loads and the file is shown \n> with line numbers, but the progress is stuck at 0% (with the   \n> showing too).\n> \n> I then tried with my two patches applied on top of e206d62 on IE8 and \n> still no success. The page loads and the file is show with the line \n> numbers but still stuck at 0%, but the   is gone at least.\n> \n> Do you have access to IE8 to confirm?\n\nI have tested gitweb with both of your patches applied, serving gitweb\nas CGI script using Apache 2.0.54 on Linux, and viewing from separate\ncomputer on MS Windows XP, with the following results:\n\n* For the following browsers blame_incremental view on gitweb/gitweb.perl\n file produces correct output, but for progress info which instead of\n ( 1%) -> ( 29%) -> (100%) looks more like ( 1%) -> (29%) -> (100%)\n\n + Firefox 3.5.5 (rv:1.9.1.5 Gecko/20091102)\n + Opera 10.01\n + Google Chrome 3.0.195.33\n\n* Testing it with IE8 (Internet Explorer 8.0.6001.18702) page loading stops\n at 0%, at the very beginning on startBlame() function\n\n IE8 shows that it finds the following errors:\n\n * \"firstChild is null or not an object\"\n line: 565, char:4\n\n a_sha1.firstChild.data = commit.sha1.substr(0, 8);\n\n It might be caused by the fact that firstChild for this case should be\n text node containing of pure whitespace:\n \n Perhaps IE8 simplifies it in \"compatability view\" mode\n\n * \"Unspecified error\" (twice)\n line: 777, char:2\n\n if (xhr.readyState === 3 && xhr.status !== 200) {\n \treturn;\n }\n\n I don't know what might be the source of error here; I suspect that the\n error position mentioned by IE8 is bogus.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"128066","messageId":"200911211556.52175.jnareb@gmail.com","threadId":"21672","inReplyTo":"200911210132.44649.jnareb@gmail.com","subject":"Re: [PATCH 0/2] jn/gitweb-blame fixes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-21T14:56:50Z","receivedAt":"2009-11-21T14:56:50Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 21 Nov 2009, Jakub Narebski wrote:\n\n> * Testing it with IE8 (Internet Explorer 8.0.6001.18702) page loading stops\n> at 0%, at the very beginning on startBlame() function\n> \n> IE8 shows that it finds the following errors:\n> \n> * \"firstChild is null or not an object\"\n> line: 565, char:4\n> \n> a_sha1.firstChild.data = commit.sha1.substr(0, 8);\n> \n> It might be caused by the fact that firstChild for this case should be\n> text node containing of pure whitespace:\n> \n> Perhaps IE8 simplifies it in \"compatibility view\" mode\n\nThis bug (be it in gitweb.js or in IE8) is fixed by the following patch:\n\n-- 8< --\ndiff --git i/gitweb/gitweb.js w/gitweb/gitweb.js\nindex 200ec5a..c1e425c 100644\n--- i/gitweb/gitweb.js\n+++ w/gitweb/gitweb.js\n@@ -562,7 +562,12 @@ function handleLine(commit, group) {\n \t\t\ttd_sha1.rowSpan = group.numlines;\n \n \t\t\ta_sha1.href = projectUrl + 'a=commit;h=' + commit.sha1;\n-\t\t\ta_sha1.firstChild.data = commit.sha1.substr(0, 8);\n+\t\t\tif (a_sha1.firstChild) {\n+\t\t\t\ta_sha1.firstChild.data = commit.sha1.substr(0, 8);\n+\t\t\t} else {\n+\t\t\t\ta_sha1.appendChild(\n+\t\t\t\t\tdocument.createTextNode(commit.sha1.substr(0, 8)));\n+\t\t\t}\n \t\t\tif (group.numlines >= 2) {\n \t\t\t\tvar fragment = document.createDocumentFragment();\n \t\t\t\tvar br = document.createElement(\"br\");\n-- >8 --\n\n> \n> * \"Unspecified error\" (twice)\n> line: 777, char:2\n> \n> if (xhr.readyState === 3 && xhr.status !== 200) {\n> \treturn;\n> }\n> \n> I don't know what might be the source of error here; I suspect that the\n> error position mentioned by IE8 is bogus.\n\nBut I have no idea how to fix this. \"Unspecified error\" isn't very \nhelpful...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"128150","messageId":"4B0A14F6.5080405@gmail.com","threadId":"21672","inReplyTo":"200911210132.44649.jnareb@gmail.com","subject":"Re: [PATCH 0/2] jn/gitweb-blame fixes","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-23T04:52:06Z","receivedAt":"2009-11-23T04:52:06Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Jakub Narebski wrote:\n> I have tested gitweb with both of your patches applied, serving gitweb\n> as CGI script using Apache 2.0.54 on Linux, and viewing from separate\n> computer on MS Windows XP, with the following results:\n>\n> * For the following browsers blame_incremental view on gitweb/gitweb.perl\n> file produces correct output, but for progress info which instead of\n> ( 1%) -> ( 29%) -> (100%) looks more like ( 1%) -> (29%) -> (100%)\n\nThis is due to an off-by-one error in the while loop. This should fix \nit. I'll probably squash this into patch 2 and resend.\n\n--->8----\n\ndiff --git a/gitweb/gitweb.js b/gitweb/gitweb.js\nindex 30597dd..9214497 100644\n--- a/gitweb/gitweb.js\n+++ b/gitweb/gitweb.js\n@@ -43,7 +43,7 @@ function padLeftStr(input, width, str) {\n var prefix = '';\n \n width -= input.toString().length;\n- while (width > 1) {\n+ while (width > 0) {\n prefix += str;\n width--;\n }\n"},{"id":"128269","messageId":"200911250145.16472.jnareb@gmail.com","threadId":"21672","inReplyTo":"200911211556.52175.jnareb@gmail.com","subject":"[PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-25T00:45:15Z","receivedAt":"2009-11-25T00:45:15Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 21 Nov 2009, Jakub Narebski wrote:\n> On Sat, 21 Nov 2009, Jakub Narebski wrote:\n> \n> > * Testing it with IE8 (Internet Explorer 8.0.6001.18702) page loading stops\n> > at 0%, at the very beginning on startBlame() function\n> > \n> > IE8 shows that it finds the following errors:\n> > \n> > * \"firstChild is null or not an object\"\n> > line: 565, char:4\n> > \n> > a_sha1.firstChild.data = commit.sha1.substr(0, 8);\n> > \n> > It might be caused by the fact that firstChild for this case should be\n> > text node containing of pure whitespace:\n> > \n> > Perhaps IE8 simplifies it in \"compatibility view\" mode\n> \n> This bug (be it in gitweb.js or in IE8) is fixed by the following patch:\n> \n> -- 8< --\n> diff --git i/gitweb/gitweb.js w/gitweb/gitweb.js\n> index 200ec5a..c1e425c 100644\n> --- i/gitweb/gitweb.js\n> +++ w/gitweb/gitweb.js\n> @@ -562,7 +562,12 @@ function handleLine(commit, group) {\n> \t\t\ttd_sha1.rowSpan = group.numlines;\n> \n> \t\t\ta_sha1.href = projectUrl + 'a=commit;h=' + commit.sha1;\n> -\t\t\ta_sha1.firstChild.data = commit.sha1.substr(0, 8);\n> +\t\t\tif (a_sha1.firstChild) {\n> +\t\t\t\ta_sha1.firstChild.data = commit.sha1.substr(0, 8);\n> +\t\t\t} else {\n> +\t\t\t\ta_sha1.appendChild(\n> +\t\t\t\t\tdocument.createTextNode(commit.sha1.substr(0, 8)));\n> +\t\t\t}\n> \t\t\tif (group.numlines >= 2) {\n> \t\t\t\tvar fragment = document.createDocumentFragment();\n> \t\t\t\tvar br = document.createElement(\"br\");\n> -- >8 --\n\nBelow the same patch is in the form of a proper commit; although the title\n(subject) of this commit could be better...\n\n> > * \"Unspecified error\" (twice)\n> > line: 777, char:2\n> > \n> > if (xhr.readyState === 3 && xhr.status !== 200) {\n> > \treturn;\n> > }\n> > \n> > I don't know what might be the source of error here; I suspect that the\n> > error position mentioned by IE8 is bogus.\n> \n> But I have no idea how to fix this. \"Unspecified error\" isn't very \n> helpful...\n\nDebugging this is serious PITA. After fix below it appears that this bug\nis some intermittent bug, depending on XMLHttpRequest timing. It more\noften than not (at least when I tried to debug it using build-in IE8\ndebugger) works correctly for the folowing files: README, GIT-VERSION-GEN,\nrevision.c (once even it did fail when first running for given file, and\nthen running correctly when reloading from debugger; fun it is not).\n\nIt does consistently fail for gitweb/gitweb.perl... but when I tried\nto debug it IE8 would hang up when trying to use debugger (with around\n600MB available RAM). Perhaps somebody else would have more luck...\n\n-- >8 --\nSubject: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame\n\nInternet Explorer 8 stops at beginning of blame filling\nwith the following bug\n \"firstChild is null or not an object\"\nat this line\n a_sha1.firstChild.data = commit.sha1.substr(0, 8);\n\nIt is (probably) caused by the fact that while a_sha1 element,\nwhich looks like this\n \nhas firstChild which is text node containing only whitespace (single\nspace character) in other web browsers (Firefox 3.5, Opera 10,\nGoogle Chrome 3.0), IE8 simplifies DOM, removing trailing/leading\nwhitespace.\n\nProtect against this bug by creating text element if it does not\nexist.\n\nFound-by: Stephen Boyd \nSigned-off-by: Jakub Narebski \n---\n gitweb/gitweb.js | 7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/gitweb/gitweb.js b/gitweb/gitweb.js\nindex 200ec5a..c1e425c 100644\n--- a/gitweb/gitweb.js\n+++ b/gitweb/gitweb.js\n@@ -562,7 +562,12 @@ function handleLine(commit, group) {\n \t\t\ttd_sha1.rowSpan = group.numlines;\n \n \t\t\ta_sha1.href = projectUrl + 'a=commit;h=' + commit.sha1;\n-\t\t\ta_sha1.firstChild.data = commit.sha1.substr(0, 8);\n+\t\t\tif (a_sha1.firstChild) {\n+\t\t\t\ta_sha1.firstChild.data = commit.sha1.substr(0, 8);\n+\t\t\t} else {\n+\t\t\t\ta_sha1.appendChild(\n+\t\t\t\t\tdocument.createTextNode(commit.sha1.substr(0, 8)));\n+\t\t\t}\n \t\t\tif (group.numlines >= 2) {\n \t\t\t\tvar fragment = document.createDocumentFragment();\n \t\t\t\tvar br = document.createElement(\"br\");\n-- \n1.6.5.3\n"},{"id":"128270","messageId":"20091125100104.6117@nanako3.lavabit.com","threadId":"21672","inReplyTo":"200911250145.16472.jnareb@gmail.com","subject":"Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-11-25T01:01:04Z","receivedAt":"2009-11-25T01:01:04Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Jakub Narebski \n\n> On Sat, 21 Nov 2009, Jakub Narebski wrote:\n>\n> Below the same patch is in the form of a proper commit; although the title\n> (subject) of this commit could be better...\n\nDoes this replace the first of the previous two-patch series? Is Stephen's second patch still needed (with his fix)?\n\nQuoting Stephen Boyd \n\n> Jakub Narebski wrote:\n>> I have tested gitweb with both of your patches applied, serving gitweb\n>> as CGI script using Apache 2.0.54 on Linux, and viewing from separate\n>> computer on MS Windows XP, with the following results:\n>>\n>> * For the following browsers blame_incremental view on gitweb/gitweb.perl\n>> file produces correct output, but for progress info which instead of\n>> ( 1%) -> ( 29%) -> (100%) looks more like ( 1%) -> (29%) -> (100%)\n>\n> This is due to an off-by-one error in the while loop. This should fix\n> it. I'll probably squash this into patch 2 and resend.\n>\n> --->8----\n>\n> diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js\n> index 30597dd..9214497 100644\n> --- a/gitweb/gitweb.js\n> +++ b/gitweb/gitweb.js\n> @@ -43,7 +43,7 @@ function padLeftStr(input, width, str) {\n> var prefix = '';\n>\n> width -= input.toString().length;\n> - while (width > 1) {\n> + while (width > 0) {\n> prefix += str;\n> width--;\n> }\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"128274","messageId":"200911250213.50684.jnareb@gmail.com","threadId":"21672","inReplyTo":"20091125100104.6117@nanako3.lavabit.com","subject":"Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-25T01:13:50Z","receivedAt":"2009-11-25T01:13:50Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 25 Nov 2009, Nanako Shiraishi wrote:\n> Quoting Jakub Narebski \n> \n> > On Sat, 21 Nov 2009, Jakub Narebski wrote:\n> >\n> > Below the same patch is in the form of a proper commit; although the title\n> > (subject) of this commit could be better...\n> \n> Does this replace the first of the previous two-patch series? Is\n> Stephen's second patch still needed (with his fix)? \n\nNo, it replaces neither first patch of Stephen's two patch series that\nstarted this thread, namely \"gitweb.js: fix null object exception in\ninitials calculation\" (which is about initials of committer... if they\nexist), nor the follow-up fix of off-by-one bug in padLeftStr.\n\nThis is fix of an independent issue (even if it occurs only in IE8).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"128280","messageId":"1259121100-4178-1-git-send-email-bebarino@gmail.com","threadId":"21672","inReplyTo":"1258659887-5244-3-git-send-email-bebarino@gmail.com","subject":"[PATCHv2 2/2] gitweb.js: fix padLeftStr() and its usage","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-25T03:51:40Z","receivedAt":"2009-11-25T03:51:40Z","isPatch":false,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"It seems that in Firefox-3.5 inserting   with javascript inserts the\nliteral   instead of a space. Fix this by inserting the unicode\nrepresentation for   instead.\n\nAlso fix the off-by-one error in the padding calculation that was\ncausing one less space to be inserted than was requested by the caller.\n\nSigned-off-by: Stephen Boyd \nCc: Jakub Narebski \n---\n\nFixed the commit message and squashed in the off-by-one bug.\n\n gitweb/gitweb.js | 10 +++++-----\n 1 files changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/gitweb/gitweb.js b/gitweb/gitweb.js\nindex 02454d8..9214497 100644\n--- a/gitweb/gitweb.js\n+++ b/gitweb/gitweb.js\n@@ -31,19 +31,19 @@\n \n /**\n * pad number N with nonbreakable spaces on the left, to WIDTH characters\n- * example: padLeftStr(12, 3, ' ') == ' 12'\n- * (' ' is nonbreakable space)\n+ * example: padLeftStr(12, 3, '\\u00A0') == '\\u00A012'\n+ * ('\\u00A0' is nonbreakable space)\n *\n * @param {Number|String} input: number to pad\n * @param {Number} width: visible width of output\n- * @param {String} str: string to prefix to string, e.g. ' '\n+ * @param {String} str: string to prefix to string, e.g. '\\u00A0'\n * @returns {String} INPUT prefixed with (WIDTH - INPUT.length) x STR\n */\n function padLeftStr(input, width, str) {\n \tvar prefix = '';\n \n \twidth -= input.toString().length;\n-\twhile (width > 1) {\n+\twhile (width > 0) {\n \t\tprefix += str;\n \t\twidth--;\n \t}\n@@ -158,7 +158,7 @@ function updateProgressInfo() {\n \n \tif (div_progress_info) {\n \t\tdiv_progress_info.firstChild.data = blamedLines + ' / ' + totalLines +\n-\t\t\t' (' + padLeftStr(percentage, 3, ' ') + '%)';\n+\t\t\t' (' + padLeftStr(percentage, 3, '\\u00A0') + '%)';\n \t}\n \n \tif (div_progress_bar) {\n-- \n1.6.6.rc0\n"},{"id":"128281","messageId":"4B0CAC2E.1060105@gmail.com","threadId":"21672","inReplyTo":"200911250145.16472.jnareb@gmail.com","subject":"Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-11-25T04:01:50Z","receivedAt":"2009-11-25T04:01:50Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Jakub Narebski wrote:\n>\n> Debugging this is serious PITA. After fix below it appears that this bug\n> is some intermittent bug, depending on XMLHttpRequest timing. It more\n> often than not (at least when I tried to debug it using build-in IE8\n> debugger) works correctly for the folowing files: README, GIT-VERSION-GEN,\n> revision.c (once even it did fail when first running for given file, and\n> then running correctly when reloading from debugger; fun it is not).\n>\n> It does consistently fail for gitweb/gitweb.perl... but when I tried\n> to debug it IE8 would hang up when trying to use debugger (with around\n> 600MB available RAM). Perhaps somebody else would have more luck...\n\nInteresting. I don't have time to look into this until early December, \nbut if it's still around then I'll take a look. I wonder if IE6 or IE7 \nworks (I don't think everyone is on version 8 yet).\n"},{"id":"128314","messageId":"200911251536.08993.jnareb@gmail.com","threadId":"21672","inReplyTo":"4B0CAC2E.1060105@gmail.com","subject":"Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-25T14:36:07Z","receivedAt":"2009-11-25T14:36:07Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 25 Nov 2009 05:01, Stephen Boyd wrote:\n> Jakub Narebski wrote:\n> >\n> > Debugging this is serious PITA. After fix below it appears that this bug\n> > is some intermittent bug, depending on XMLHttpRequest timing. It more\n> > often than not (at least when I tried to debug it using build-in IE8\n> > debugger) works correctly for the folowing files: README, GIT-VERSION-GEN,\n> > revision.c (once even it did fail when first running for given file, and\n> > then running correctly when reloading from debugger; fun it is not).\n> >\n> > It does consistently fail for gitweb/gitweb.perl... but when I tried\n> > to debug it IE8 would hang up when trying to use debugger (with around\n> > 600MB available RAM). Perhaps somebody else would have more luck...\n> \n> Interesting. I don't have time to look into this until early December, \n> but if it's still around then I'll take a look. I wonder if IE6 or IE7 \n> works (I don't think everyone is on version 8 yet).\n\nWell, the one time I was able to run debugger (F12, select 'Script', select\n'gitweb.js') with error occurring and without IE hanging (for README file)\nit did show an error for the following line:\n\n if (xhr.readyState === 3 && xhr.status !== 200) {\n\nWhen I checked 'xhr' object, it has \"Unknown error\" as contents of \nxhr.statusText field and as contents of xhr.status (sic!), which should\nbe a number: HTTP status code.\n\nUnfortunately I had to take a break... and I was not able to reproduce this\n(without hanging web browser: \"program not responding\") since then...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"128341","messageId":"200911252155.59318.jnareb@gmail.com","threadId":"21672","inReplyTo":"200911251536.08993.jnareb@gmail.com","subject":"Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-25T20:55:58Z","receivedAt":"2009-11-25T20:55:58Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 25 Nov 2009, Jakub Narebski wrote:\n> On Wed, 25 Nov 2009 05:01, Stephen Boyd wrote:\n> > Jakub Narebski wrote:\n> > >\n> > > Debugging this is serious PITA. After fix below it appears that this bug\n> > > is some intermittent bug, depending on XMLHttpRequest timing. It more\n> > > often than not (at least when I tried to debug it using build-in IE8\n> > > debugger) works correctly for the folowing files: README, GIT-VERSION-GEN,\n> > > revision.c (once even it did fail when first running for given file, and\n> > > then running correctly when reloading from debugger; fun it is not).\n> > >\n> > > It does consistently fail for gitweb/gitweb.perl... but when I tried\n> > > to debug it IE8 would hang up when trying to use debugger (with around\n> > > 600MB available RAM). Perhaps somebody else would have more luck...\n> > \n> > Interesting. I don't have time to look into this until early December, \n> > but if it's still around then I'll take a look. I wonder if IE6 or IE7 \n> > works (I don't think everyone is on version 8 yet).\n> \n> Well, the one time I was able to run debugger (F12, select 'Script', select\n> 'gitweb.js') with error occurring\n\nThe error was \"Unspecified error\", char:2 in the mentioned line\n\n> and without IE hanging (for README file) it did show an error for the\n> following line: \n> \n> if (xhr.readyState === 3 && xhr.status !== 200) {\n> \n> When I checked 'xhr' object, it has \"Unknown error\" as contents of \n> xhr.statusText field and as contents of xhr.status (sic!), which should\n> be a number: HTTP status code.\n\nIt was 'Unspecified error.' shown in xhr watch. Accessing xhr.status\ncauses an error.\n\nThis might be cause by the fact that xhr (XMLHttpRequest object, or as IE8\nshows it in JScript debugger DispHTMLXMLHttpRequest object) is not fully\ninitialized, or something; gitweb.js calls handleResponse() also from\na timer, to work around the fact that some web browsers onreadystatechange\nhandler is called only once for each state, and not as soon as new data\nis available from server.\n\nLonger term solution would be to use onprogress handler if it is available;\nif it is available we don't need trick with calling handleResponse from\ntimer, as XMLHttpRequest 2.0 proposed specification ensures calling callback\nas soon as new data is available.\n\nShort term solution would be to wrap access to xhr.status in try ... catch\nblock for IE8... although I am a bit reluctant to implement this workaround\nbugs in IE8.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"128346","messageId":"7vd436s2r8.fsf@alter.siamese.dyndns.org","threadId":"21672","inReplyTo":"200911252155.59318.jnareb@gmail.com","subject":"Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-25T21:39:23Z","receivedAt":"2009-11-25T21:39:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> It was 'Unspecified error.' shown in xhr watch. Accessing xhr.status\n> causes an error.\n\nAs to the topic, it does not seem to break _existing_ features; if that is\nnot the case, please let me know.\n\nOtherwise I'm inclined to merge the entire series to 'master' by 1.6.6-rc1.\n\n 6821dee gitweb.js: fix padLeftStr() and its usage\n 6aa2de5 gitweb.js: Harden setting blamed commit info in incremental blame\n e42a05f gitweb.js: fix null object exception in initials calculation\n 63267de gitweb: Minify gitweb.js if JSMIN is defined\n c4ccf61 gitweb: Create links leading to 'blame_incremental' using JavaScript\n e206d62 gitweb: Colorize 'blame_incremental' view during processing\n 4af819d gitweb: Incremental blame (using JavaScript)\n aa7dd05 gitweb: Add optional \"time to generate page\" info in footer\n -aef3768 gitweb: Use light/dark for class names also in 'blame' view\n\nand treat it as a new feature with known breakages, to give it wider\naudience. That way you will hopefully get more people who are willing to\nhelp debug/fix things for you.\n"},{"id":"128369","messageId":"200911260028.19383.jnareb@gmail.com","threadId":"21672","inReplyTo":"7vd436s2r8.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-25T23:28:18Z","receivedAt":"2009-11-25T23:28:18Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, środa 25. listopada 2009 22:39, Junio C Hamano napisał:\n> Jakub Narebski writes:\n> \n> > It was 'Unspecified error.' shown in xhr watch. Accessing xhr.status\n> > causes an error.\n> \n> As to the topic, it does not seem to break _existing_ features; if that is\n> not the case, please let me know.\n\nWith the single exception of \"Create links leading to 'blame_incremental'\nusing JavaScript\" all commits are about opt-in features: either need to\nbe enabled in gitweb config ('timed' feature), or you need to handcraft\nURL ('blame_incremental' as action parameter).\n\nThe commit that makes 'blame' links to use 'blame_incremental' view if\nJavaScript is enabled might break 'blame' view for IE8 users.\n\n> Otherwise I'm inclined to merge the entire series to 'master' by 1.6.6-rc1.\n> \n> 6821dee gitweb.js: fix padLeftStr() and its usage\n> 6aa2de5 gitweb.js: Harden setting blamed commit info in incremental blame\n> e42a05f gitweb.js: fix null object exception in initials calculation\n> 63267de gitweb: Minify gitweb.js if JSMIN is defined\n> c4ccf61 gitweb: Create links leading to 'blame_incremental' using JavaScript\n> e206d62 gitweb: Colorize 'blame_incremental' view during processing\n> 4af819d gitweb: Incremental blame (using JavaScript)\n> aa7dd05 gitweb: Add optional \"time to generate page\" info in footer\n> -aef3768 gitweb: Use light/dark for class names also in 'blame' view\n> \n> and treat it as a new feature with known breakages, to give it wider\n> audience. That way you will hopefully get more people who are willing to\n> help debug/fix things for you.\n\nPerhaps then it would be better to put commit that creates links to \n'blame_incremental' action last, and have it in 'next' and not in master?\n\nBelow there is request-pull with reordered series, unless you want me\nto resend this series as a set of patches, as reply to this email.\n\n-- >8 --\nThe following changes since commit b073b7a990deb1cb3425db45642fa18c8b3cb65c:\n Benjamin Kramer (1):\n Explicitly truncate bswap operand to uint32_t\n\nare available in the git repository at:\n\n git://repo.or.cz/git/jnareb-git.git gitweb/web\n\n 7bc7e38 gitweb: Create links leading to 'blame_incremental' using JavaScript\n aa1ff3d gitweb.js: Harden setting blamed commit info in incremental blame\n da51a3c gitweb.js: fix padLeftStr() and its usage\n a253a2c gitweb.js: fix null object exception in initials calculation\n fbebd29 gitweb: Minify gitweb.js if JSMIN is defined\n 8ba6343 gitweb: Colorize 'blame_incremental' view during processing\n 0e14278 gitweb: Incremental blame (using JavaScript)\n c4c6645 gitweb: Add optional \"time to generate page\" info in foot\n\nJakub Narebski (6):\n gitweb: Add optional \"time to generate page\" info in footer\n gitweb: Incremental blame (using JavaScript)\n gitweb: Colorize 'blame_incremental' view during processing\n gitweb: Minify gitweb.js if JSMIN is defined\n gitweb.js: Harden setting blamed commit info in incremental blame\n gitweb: Create links leading to 'blame_incremental' using JavaScript\n\nStephen Boyd (2):\n gitweb.js: fix null object exception in initials calculation\n gitweb.js: fix padLeftStr() and its usage\n\n Makefile | 26 ++-\n git-instaweb.sh | 7 +\n gitweb/README | 5 +\n gitweb/gitweb.css | 25 ++\n gitweb/gitweb.js | 870 ++++++++++++++++++++++++++++++++++++++++++++++++++++\n gitweb/gitweb.perl | 311 ++++++++++++++-----\n 6 files changed, 1157 insertions(+), 87 deletions(-)\n create mode 100644 gitweb/gitweb.js\n\n-- \nJakub Narebski\nPoland\n"},{"id":"128384","messageId":"7vpr76m8dx.fsf@alter.siamese.dyndns.org","threadId":"21672","inReplyTo":"200911260028.19383.jnareb@gmail.com","subject":"Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-26T00:34:18Z","receivedAt":"2009-11-26T00:34:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Below there is request-pull with reordered series, unless you want me\n> to resend this series as a set of patches, as reply to this email.\n\nIt is too late for that, as they are already in 'next'. I do not think it\nis necessary nor desirable, either.\n\nWith the \"Create links\" commit, you are _adding_ a new link that leads to\na new feature with known breakage, not _replacing_ a link that leads to an\nexisting working implementation with one that does not work for some\npeople, no?\n\nMerging everything else but not merging that commit does not make any\nsense. It won't give any wider exposure to the feature, and is no better\nthan carrying the entire thing in 'next' (or 'pu') post 1.6.6.\n\nA follow-up patch to add a gitweb configuration switch that disables the\nnon-working view by default but allows site owners to enable it in order\nto help improving the feature would be a sensible thing to do. As long as\nthat patch is solidly done we can merge the whole thing to 'master' in the\nupcoming release.\n"},{"id":"128415","messageId":"200911260159.48311.jnareb@gmail.com","threadId":"21672","inReplyTo":"7vpr76m8dx.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-26T00:59:47Z","receivedAt":"2009-11-26T00:59:47Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 26 Nov 2009, Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n> > Below there is request-pull with reordered series, unless you want me\n> > to resend this series as a set of patches, as reply to this email.\n> \n> It is too late for that, as they are already in 'next'. I do not think it\n> is necessary nor desirable, either.\n> \n> With the \"Create links\" commit, you are _adding_ a new link that leads to\n> a new feature with known breakage, not _replacing_ a link that leads to an\n> existing working implementation with one that does not work for some\n> people, no?\n\nNo. The \"Create links\" commits make existing 'blame' links, which till that\ncommit always lead to non-incremental 'blame' action, now lead to new\n'blame_incremental' action (if JavaScript is enabled). So the result is\nthat we _replace_ links to 'blame' view by links to 'blame_incremental' view.\n\n> Merging everything else but not merging that commit does not make any\n> sense. It won't give any wider exposure to the feature, and is no better\n> than carrying the entire thing in 'next' (or 'pu') post 1.6.6.\n> \n> A follow-up patch to add a gitweb configuration switch that disables the\n> non-working view by default but allows site owners to enable it in order\n> to help improving the feature would be a sensible thing to do. As long as\n> that patch is solidly done we can merge the whole thing to 'master' in the\n> upcoming release.\n\nBut if it is already in 'next', then I'll try to come up with patch which\nmakes JavaScript-ing links (replacing links with JavaScript to equivalent\nactions utilizing JavaScript, currently only 'blame' -> 'blame_incremental')\nconfigurable.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"128500","messageId":"200911262112.16280.jnareb@gmail.com","threadId":"21672","inReplyTo":"200911260159.48311.jnareb@gmail.com","subject":"[RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-26T20:12:15Z","receivedAt":"2009-11-26T20:12:15Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 26 Nov 2009, Jakub Narebski wrote:\n> On Thu, 26 Nov 2009, Junio C Hamano wrote:\n\n> > A follow-up patch to add a gitweb configuration switch that disables the\n> > non-working view by default but allows site owners to enable it in order\n> > to help improving the feature would be a sensible thing to do. As long as\n> > that patch is solidly done we can merge the whole thing to 'master' in the\n> > upcoming release.\n> \n> But if it is already in 'next', then I'll try to come up with patch which\n> makes JavaScript-ing links (replacing links with JavaScript to equivalent\n> actions utilizing JavaScript, currently only 'blame' -> 'blame_incremental')\n> configurable.\n\nHere it is. I am a bit ambiguous about *naming* of this feature (and\nwhether it should be overridable), that's why it is marked as RFC.\n\nAlso the subject of this commit could have been better, I think...\n\n-- >8 --\nLet gitweb turn some links (like 'blame' links) into linking to\nactions which require JavaScript (like 'blame_incremental' action)\nonly if 'javascript-actions' feature is enabled.\n\nThis means that links to such actions would be present only if both\nJavaScript is enabled and 'javascript-actions' feature is enabled.\n\nSigned-off-by: Jakub Narebski \n---\n gitweb/gitweb.perl | 9 ++++++++-\n 1 files changed, 8 insertions(+), 1 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex a80cbd3..0ab47e1 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -432,6 +432,13 @@ our %feature = (\n \t'timed' => {\n \t\t'override' => 0,\n \t\t'default' => [0]},\n+\n+\t# Enable turning some links into links to actions which require\n+\t# JavaScript to run (like 'blame_incremental'). Enabled by default.\n+\t# Project specific override is currently not supported.\n+\t'javascript-actions' => {\n+\t\t'override' => 0,\n+\t\t'default' => [1]},\n );\n \n sub gitweb_get_feature {\n@@ -3326,7 +3333,7 @@ sub git_footer_html {\n \t\t qq!startBlame(\"!. href(action=>\"blame_data\", -replay=>1) .qq!\",\\n!.\n \t\t qq! \"!. href() .qq!\");\\n!.\n \t\t qq!\\n!;\n-\t} else {\n+\t} elsif (gitweb_check_feature('javascript-actions')) {\n \t\tprint qq!\\n!;\n-- \n1.6.5.3\n"},{"id":"128501","messageId":"7vws1d3tzk.fsf@alter.siamese.dyndns.org","threadId":"21672","inReplyTo":"200911262112.16280.jnareb@gmail.com","subject":"Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-26T20:34:55Z","receivedAt":"2009-11-26T20:34:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Let gitweb turn some links (like 'blame' links) into linking to\n> actions which require JavaScript (like 'blame_incremental' action)\n> only if 'javascript-actions' feature is enabled.\n\nHmm, instead of \"fixLinks\" that actually munges existing links to working\naction with some other action, can that be \"addLinks\" that _adds_ new\nlinks to features available only when JS can be used?\n"},{"id":"128503","messageId":"200911262224.36371.jnareb@gmail.com","threadId":"21672","inReplyTo":"7vws1d3tzk.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-26T21:24:35Z","receivedAt":"2009-11-26T21:24:35Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia czwartek 26. listopada 2009 21:34, Junio C Hamano napisał:\n> Jakub Narebski writes:\n> \n> > Let gitweb turn some links (like 'blame' links) into linking to\n> > actions which require JavaScript (like 'blame_incremental' action)\n> > only if 'javascript-actions' feature is enabled.\n> \n> Hmm, instead of \"fixLinks\" that actually munges existing links to working\n> action with some other action, can that be \"addLinks\" that _adds_ new\n> links to features available only when JS can be used?\n\nI am not sure if this would make sense.\n\nBoth 'blame' (running \"git blame --porcelain\") and 'blame_incremental'\n(running \"git blame --incremental\") actions generate *the same* view,\nmodulo some very minor differences. The idea behind 'blame_incremental'\nis that it provides incremental updates to long-running action, and\nhopefully also reduce server load, at least a bit.\n\n\nIt might be however good *interim* solution, so people would be able\nto test 'blame_incremental' view without having to edit gitweb links.\nHmmm....\n\n-- \nJakub Narebski\nPoland\n"},{"id":"128522","messageId":"7vy6lsy9mi.fsf@alter.siamese.dyndns.org","threadId":"21672","inReplyTo":"200911262224.36371.jnareb@gmail.com","subject":"Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-27T02:39:01Z","receivedAt":"2009-11-27T02:39:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> It might be however good *interim* solution, so people would be able\n> to test 'blame_incremental' view without having to edit gitweb links.\n\nExactly. I thought you were responding to my earlier \"ship it as a new\nfeature with known breakage so that people can choose to enable to help\ndebugging and fixing\". If flipping on the new implementation makes an\nalternative working implementation unavailable, that would be one reason\nthe site owners might consider _not_ enabling it. By making them both\navailable, the result will have one less reason not to try for site\nowners.\n"},{"id":"128570","messageId":"200911271641.40947.jnareb@gmail.com","threadId":"21672","inReplyTo":"7vy6lsy9mi.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-11-27T15:41:39Z","receivedAt":"2009-11-27T15:41:39Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 27 Nov 2009, Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n> > It might be however good *interim* solution, so people would be able\n> > to test 'blame_incremental' view without having to edit gitweb links.\n> \n> Exactly. I thought you were responding to my earlier \"ship it as a new\n> feature with known breakage so that people can choose to enable to help\n> debugging and fixing\". If flipping on the new implementation makes an\n> alternative working implementation unavailable, that would be one reason\n> the site owners might consider _not_ enabling it. By making them both\n> available, the result will have one less reason not to try for site\n> owners.\n\nActually \"addLinks\" would be a bit harder, I guess, than current \"fixLinks\"\nbecause \"fixLinks\" just adds ';js=1' to URL to denote that gitweb can use\nJavaScript-requiring actions equivalents. For \"addLinks\" selecting where\nto add links would have to be in gitweb.js\n\nI can \"borrow\" some code from Martin Koegler patch from April 2007\n\"[PATCH 5/7] gitweb: Prototyp for selecting diffs in JavaScript\"\nMessage-Id: <1176669971921-git-send-email-mkoegler@auto.tuwien.ac.at>\n$gmane/44517/focus=44523. \n\nWould turning\n\n \"blame\"\n\nlink ito pair of links\n\n \"blame (incremental)\"\n\nbe a good solution? I'm trying to come up with good naming for extra link\nto 'blame_incremental' action...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"128589","messageId":"7veinjn7nc.fsf@alter.siamese.dyndns.org","threadId":"21672","inReplyTo":"200911271641.40947.jnareb@gmail.com","subject":"Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-27T18:29:27Z","receivedAt":"2009-11-27T18:29:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Would turning\n>\n> \"blame\"\n>\n> link ito pair of links\n>\n> \"blame (incremental)\"\n>\n> be a good solution? I'm trying to come up with good naming for extra link\n> to 'blame_incremental' action...\n\nI had to step back a bit and ask myself what we are trying to achieve\nhere. When the current blame and incremental one are both working\nperfectly and well, will there be a reason for the end users to choose\nbetween them when they click?\n\nMy answer is no. If the incremental one gives nicer user experience in\nall cases, it will be shown without the non-incremental one; if the\nincremental one makes the server or network load too heavy, a site owner\nmay decide to show only the non-incremental one.\n\nThat makes my addLinks suggestion a change that would help _only_ while we\nare working kinks out of the incremental one.\n\nLet's not waste too much effort doing that. Sorry for suggesting.\n\nLetting the site owner choose if the site wants to set the \"incremental if\npossible\" boolean would be more than adequate, I think.\n"},{"id":"128829","messageId":"7v4oob8pap.fsf@alter.siamese.dyndns.org","threadId":"21672","inReplyTo":"7veinjn7nc.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-01T01:18:38Z","receivedAt":"2009-12-01T01:18:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I had to step back a bit and ask myself what we are trying to achieve\n> here. When the current blame and incremental one are both working\n> perfectly and well, will there be a reason for the end users to choose\n> between them when they click?\n>\n> My answer is no. If the incremental one gives nicer user experience in\n> all cases, it will be shown without the non-incremental one; if the\n> incremental one makes the server or network load too heavy, a site owner\n> may decide to show only the non-incremental one.\n>\n> That makes my addLinks suggestion a change that would help _only_ while we\n> are working kinks out of the incremental one.\n>\n> Let's not waste too much effort doing that. Sorry for suggesting.\n>\n> Letting the site owner choose if the site wants to set the \"incremental if\n> possible\" boolean would be more than adequate, I think.\n\nSorry, but I guess I dropped the ball after this message. If I understand\ncorrectly, the conclusion is that I can apply the patch in this one\n\n From: Jakub Narebski \n Subject: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature\n Date: Thu, 26 Nov 2009 21:12:15 +0100\n Message-ID: <200911262112.16280.jnareb@gmail.com>\n\nand shipping 1.6.6 with it (perhaps setting 'default' to '[0]' instead)\nwould be both reasonably safe and allows easy experimentation by willing\nsite owners (or individual gitweb deployment), right?\n\nPlease advice if I am mistaken.\n\nThanks.\n"},{"id":"128895","messageId":"200912011751.12172.jnareb@gmail.com","threadId":"21672","inReplyTo":"7v4oob8pap.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-12-01T16:51:11Z","receivedAt":"2009-12-01T16:51:11Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 1 Dec 2009, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > I had to step back a bit and ask myself what we are trying to achieve\n> > here. When the current blame and incremental one are both working\n> > perfectly and well, will there be a reason for the end users to choose\n> > between them when they click?\n> >\n> > My answer is no. If the incremental one gives nicer user experience in\n> > all cases, it will be shown without the non-incremental one; if the\n> > incremental one makes the server or network load too heavy, a site owner\n> > may decide to show only the non-incremental one.\n> >\n> > That makes my addLinks suggestion a change that would help _only_ while we\n> > are working kinks out of the incremental one.\n> >\n> > Let's not waste too much effort doing that. Sorry for suggesting.\n> >\n> > Letting the site owner choose if the site wants to set the \"incremental if\n> > possible\" boolean would be more than adequate, I think.\n> \n> Sorry, but I guess I dropped the ball after this message. If I understand\n> correctly, the conclusion is that I can apply the patch in this one\n> \n> From: Jakub Narebski \n> Subject: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature\n> Date: Thu, 26 Nov 2009 21:12:15 +0100\n> Message-ID: <200911262112.16280.jnareb@gmail.com>\n> \n> and shipping 1.6.6 with it (perhaps setting 'default' to '[0]' instead)\n> would be both reasonably safe and allows easy experimentation by willing\n> site owners (or individual gitweb deployment), right?\n\nYes, I think it is right.\n\nAs a followup to this mail I have sent modified version of patch mentioned\nabove, only with default setting for 'javascript-actions' changed to '[0]'\n(disabled), and new patch adding link to 'blame_incremental' action in an\nordinary 'blame' view and vice versa, so even if 'javascript-actions' is\nturned off one can experiment with AJAX-y blame.\n\n gitweb/gitweb.perl | 21 +++++++++++++++++++--\n 1 files changed, 19 insertions(+), 2 deletions(-)\n\n-- \nJakub Narebski\nPoland\n"},{"id":"128896","messageId":"200912011752.04986.jnareb@gmail.com","threadId":"21672","inReplyTo":"200912011751.12172.jnareb@gmail.com","subject":"[PATCH 1/2] gitweb: Make linking to actions requiring JavaScript a feature","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-12-01T16:52:04Z","receivedAt":"2009-12-01T16:52:04Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Let gitweb turn some links (like 'blame' links) into linking to\nactions which require JavaScript (like 'blame_incremental' action)\nonly if 'javascript-actions' feature is enabled.\n\nThis means that links to such actions would be present only if both\nJavaScript is enabled, and 'javascript-actions' feature is enabled.\n\nSigned-off-by: Jakub Narebski \n---\n gitweb/gitweb.perl | 9 ++++++++-\n 1 files changed, 8 insertions(+), 1 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex a80cbd3..bb2d29c 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -432,6 +432,13 @@ our %feature = (\n \t'timed' => {\n \t\t'override' => 0,\n \t\t'default' => [0]},\n+\n+\t# Enable turning some links into links to actions which require\n+\t# JavaScript to run (like 'blame_incremental'). Disabled by default.\n+\t# Project specific override is currently not supported.\n+\t'javascript-actions' => {\n+\t\t'override' => 0,\n+\t\t'default' => [0]},\n );\n \n sub gitweb_get_feature {\n@@ -3326,7 +3333,7 @@ sub git_footer_html {\n \t\t qq!startBlame(\"!. href(action=>\"blame_data\", -replay=>1) .qq!\",\\n!.\n \t\t qq! \"!. href() .qq!\");\\n!.\n \t\t qq!\\n!;\n-\t} else {\n+\t} elsif (gitweb_check_feature('javascript-actions')) {\n \t\tprint qq!\\n!;\n-- \n1.6.5.3\n"},{"id":"128898","messageId":"200912011754.27455.jnareb@gmail.com","threadId":"21672","inReplyTo":"200912011751.12172.jnareb@gmail.com","subject":"[PATCH 2/2] gitweb: Add link to other blame implementation in blame views","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-12-01T16:54:26Z","receivedAt":"2009-12-01T16:54:26Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Add link to 'blame_incremental' action (which requires JavaScript) in\n'blame' view, and add link to 'blame' action in 'blame_incremental'\nview.\n\nSigned-off-by: Jakub Narebski \n---\n gitweb/gitweb.perl | 11 +++++++++++\n 1 files changed, 11 insertions(+), 0 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex bb2d29c..ca36761 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -5006,6 +5006,17 @@ sub git_blame_common {\n \tmy $formats_nav =\n \t\t$cgi->a({-href => href(action=>\"blob\", -replay=>1)},\n \t\t \"blob\") .\n+\t\t\" | \";\n+\tif ($format eq 'incremental') {\n+\t\t$formats_nav .=\n+\t\t\t$cgi->a({-href => href(action=>\"blame\", javascript=>0, -replay=>1)},\n+\t\t\t \"blame\") . \" (non-incremental)\";\n+\t} else {\n+\t\t$formats_nav .=\n+\t\t\t$cgi->a({-href => href(action=>\"blame_incremental\", -replay=>1)},\n+\t\t\t \"blame\") . \" (incremental)\";\n+\t}\n+\t$formats_nav .=\n \t\t\" | \" .\n \t\t$cgi->a({-href => href(action=>\"history\", -replay=>1)},\n \t\t \"history\") .\n-- \n1.6.5.3\n"},{"id":"129371","messageId":"1260147860.1579.47.camel@swboyd-laptop","threadId":"21672","inReplyTo":"200911251536.08993.jnareb@gmail.com","subject":"Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-12-07T01:04:20Z","receivedAt":"2009-12-07T01:04:20Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"On Wed, 2009-11-25 at 15:36 +0100, Jakub Narebski wrote:\n> Well, the one time I was able to run debugger (F12, select 'Script', select\n> 'gitweb.js') with error occurring and without IE hanging (for README file)\n> it did show an error for the following line:\n> \n> if (xhr.readyState === 3 && xhr.status !== 200) {\n> \n> When I checked 'xhr' object, it has \"Unknown error\" as contents of \n> xhr.statusText field and as contents of xhr.status (sic!), which should\n> be a number: HTTP status code.\n> \n> Unfortunately I had to take a break... and I was not able to reproduce this\n> (without hanging web browser: \"program not responding\") since then...\n> \n\nOk. It's December and I've had some more time to look into this.\nInitializing 'xhr' to null seems to get rid of the \"Unknown error\"\nproblem (see patch below).\n\nThe responsiveness on IE8 is pretty poor. I load the page and then after\nsome waiting (usually 20-30 seconds including IE becoming a \"Not\nResponding\" program) the whole page will load. There is nothing\nincremental about it. I'm trying to figure out why it's slow now.\n\n--->8----\n\nSubject: [PATCH] gitweb.js: workaround IE8 \"Unknown error\"\n\nInternet Explorer 8 complains about an \"Unknown error on line 782, char 2\".\nThat line is a reference to xhr and the status code. By initializing xhr\nto null this error goes away.\n\nSigned-off-by: Stephen Boyd \n---\n gitweb/gitweb.js | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/gitweb/gitweb.js b/gitweb/gitweb.js\nindex 2a25b7c..b936635 100644\n--- a/gitweb/gitweb.js\n+++ b/gitweb/gitweb.js\n@@ -126,7 +126,7 @@ function createRequestObject() {\n /* ============================================================ */\n /* utility/helper functions (and variables) */\n\n-var xhr; // XMLHttpRequest object\n+var xhr = null; // XMLHttpRequest object\n var projectUrl; // partial query + separator ('?' or ';')\n\n // 'commits' is an associative map. It maps SHA1s to Commit objects.\n-- \n1.6.6.rc1.39.g9a42\n"},{"id":"129372","messageId":"1260148741.1579.50.camel@swboyd-laptop","threadId":"21672","inReplyTo":"1260147860.1579.47.camel@swboyd-laptop","subject":"Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-12-07T01:19:01Z","receivedAt":"2009-12-07T01:19:01Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"On Sun, 2009-12-06 at 17:04 -0800, Stephen Boyd wrote:\n> \n> Ok. It's December and I've had some more time to look into this.\n> Initializing 'xhr' to null seems to get rid of the \"Unknown error\"\n> problem (see patch below).\n> \n\nAh sorry. Seems this doesn't work and I was just getting lucky.\n"},{"id":"129557","messageId":"200912081729.11890.jnareb@gmail.com","threadId":"21672","inReplyTo":"1260148741.1579.50.camel@swboyd-laptop","subject":"PATCH/RFC] gitweb.js: Workaround for IE8 bug","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-12-08T16:29:10Z","receivedAt":"2009-12-08T16:29:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 7 Dec 2009, Stephen Boyd wrote:\n> On Sun, 2009-12-06 at 17:04 -0800, Stephen Boyd wrote:\n> > \n> > Ok. It's December and I've had some more time to look into this.\n> > Initializing 'xhr' to null seems to get rid of the \"Unknown error\"\n> > problem (see patch below).\n> > \n> \n> Ah sorry. Seems this doesn't work and I was just getting lucky.\n\nDoes the following fixes the issue for IE8 for you (it works for me)?\n\nAs for testing, try with blaming 'revision.c' and 'gitweb/gitweb.perl'\nusing 'blame_incremental' view.\n\n\nWith probably too long commit message, and not detailed enough title:\n\n-- >8 --\nSubject: [PATCH] gitweb.js: Workaround for IE8 bug\n\nIn Internet Explorer 8 (IE8) the 'blame_incremental' view, which uses\nJavaScript to generate blame info using AJAX, sometimes hang at the\nbeginning (at 0%) of blaming, e.g. for larger files with long history\nlike git's own gitweb/gitweb.perl.\n\nThe error shown by JavaScript console is \"Unspecified error\" at char:2\nof the following line in gitweb/gitweb.js:\n\n if (xhr.readyState === 3 && xhr.status !== 200) {\n\nDebugging it using IE8 JScript debuger shown that the error occurs\nwhen trying to access xhr.status (xhr is XMLHttpRequest object).\nWatch for xhr object shows 'Unspecified error.' as \"value\" of\nxhr.status, and trying to access xhr.status from console throws error.\n\nThis bug is some intermittent bug, depending on XMLHttpRequest timing,\nas it doesn't occur in all cases. It is probably caused by the fact\nthat handleResponse is called from timer (pollTimer), to work around\nthe fact that some browsers call onreadystatechange handler only once\nfor each state change, and not like required for 'blame_incremental'\nas soon as new data is available from server. It looks like xhr\nobject is not properly initialized; still it is a bug to throw an\nerror when accessing xhr.status (and not use 'null' or 'undefined' as\nvalue).\n\nWork around this bug in IE8 by using try-catch block when accessing\nxhr.status.\n\nSigned-off-by: Jakub Narebski \n---\n gitweb/gitweb.js | 7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/gitweb/gitweb.js b/gitweb/gitweb.js\nindex 2a25b7c..9c66928 100644\n--- a/gitweb/gitweb.js\n+++ b/gitweb/gitweb.js\n@@ -779,7 +779,12 @@ function handleResponse() {\n \t}\n \n \t// the server returned error\n-\tif (xhr.readyState === 3 && xhr.status !== 200) {\n+\t// try ... catch block is to work around bug in IE8\n+\ttry {\n+\t\tif (xhr.readyState === 3 && xhr.status !== 200) {\n+\t\t\treturn;\n+\t\t}\n+\t} catch (e) {\n \t\treturn;\n \t}\n \tif (xhr.readyState === 4 && xhr.status !== 200) {\n-- \n1.6.5.3\n"},{"id":"129578","messageId":"1260309382.5658.41.camel@swboyd-laptop","threadId":"21672","inReplyTo":"200912081729.11890.jnareb@gmail.com","subject":"Re: PATCH/RFC] gitweb.js: Workaround for IE8 bug","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-12-08T21:56:22Z","receivedAt":"2009-12-08T21:56:22Z","isPatch":false,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"On Tue, 2009-12-08 at 17:29 +0100, Jakub Narebski wrote: \n> \n> Does the following fixes the issue for IE8 for you (it works for me)?\n> \n\nYes, there is no longer an error but IE8 still locks up and takes about\n30 seconds. It doesn't seem to be any more responsive. Isn't putting the\nerror in a try-catch just papering over the issue?\n"},{"id":"129581","messageId":"200912082324.49825.jnareb@gmail.com","threadId":"21672","inReplyTo":"1260309382.5658.41.camel@swboyd-laptop","subject":"Re: PATCH/RFC] gitweb.js: Workaround for IE8 bug","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-12-08T22:24:48Z","receivedAt":"2009-12-08T22:24:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 8 Dec 2009, Stephen Boyd wrote:\n> On Tue, 2009-12-08 at 17:29 +0100, Jakub Narebski wrote: \n> > \n> > Does the following fixes the issue for IE8 for you (it works for me)?\n> > \n> \n> Yes, there is no longer an error but IE8 still locks up and takes about\n> 30 seconds. It doesn't seem to be any more responsive. Isn't putting the\n> error in a try-catch just papering over the issue?\n\nWell, I wrote it is *workaround* for IE8 bug, didn't I?\n\nThere are actually two separate issues. First is 'blame_incremental'\nfreezing browser (making it non responsive), second is proper solution\nto this bug.\n\nThe problem with 'blame_incremental' freezing is that JavaScript is\nsingle-threaded, and that modifying DOM is not lightweight. gitweb.js\nshould then use technique described in\n http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/\nto avoid freezing browser, and perhaps also some technique to avoid\nreflowing (if possible).\n\nThe proper solution for IE8 bug would be to use 'progress', 'error'\nand 'load' events of XHR 2.0 (XMLHttpRequest specification level 2)\nif they are available, instead of mucking with underspecified \n'readystatechange' event from XHR 1.0 and timer. But it is a more\ncomplicated solution.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"129582","messageId":"200912082332.29925.jnareb@gmail.com","threadId":"21672","inReplyTo":"1260309382.5658.41.camel@swboyd-laptop","subject":"Re: PATCH/RFC] gitweb.js: Workaround for IE8 bug","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-12-08T22:32:29Z","receivedAt":"2009-12-08T22:32:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia wtorek 8. grudnia 2009 22:56, Stephen Boyd napisał:\n> On Tue, 2009-12-08 at 17:29 +0100, Jakub Narebski wrote: \n> > \n> > Does the following fixes the issue for IE8 for you (it works for me)?\n> > \n> \n> Yes, there is no longer an error but IE8 still locks up and takes about\n> 30 seconds. It doesn't seem to be any more responsive. Isn't putting the\n> error in a try-catch just papering over the issue?\n\nDoes increasing interval in setInterval call at the end of startBlame\nfinction in gitweb.js from 1000 (1 second) to e.g. 2000 (2 seconds)\nhelp there?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"129591","messageId":"1260317338.5658.101.camel@swboyd-laptop","threadId":"21672","inReplyTo":"200912082332.29925.jnareb@gmail.com","subject":"Re: PATCH/RFC] gitweb.js: Workaround for IE8 bug","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-12-09T00:08:58Z","receivedAt":"2009-12-09T00:08:58Z","isPatch":false,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"On Tue, 2009-12-08 at 23:32 +0100, Jakub Narebski wrote:\n> Dnia wtorek 8. grudnia 2009 22:56, Stephen Boyd napisał:\n> > Yes, there is no longer an error but IE8 still locks up and takes about\n> > 30 seconds. It doesn't seem to be any more responsive. Isn't putting the\n> > error in a try-catch just papering over the issue?\n> \n> Does increasing interval in setInterval call at the end of startBlame\n> finction in gitweb.js from 1000 (1 second) to e.g. 2000 (2 seconds)\n> help there?\n> \n\nI tried numbers from 100 to 10000 and didn't see a difference. Files\nwith only a few hundred lines or less don't lock up though. I've been\nusing builtin-apply.c for testing.\n"}]}