Fossil SCM
Fix an = vs == bug in the /chat timeout error handling which only coincidentally worked that way. Update some /chat-internal docs.
Commit
5fc2f2a034197efbc8469347cd4c758f62802a04f60cfdbf32422884767c3337
Parent
a5521984c32fae7…
1 file changed
+20
-10
+20
-10
| --- src/fossil.page.chat.js | ||
| +++ src/fossil.page.chat.js | ||
| @@ -2633,10 +2633,11 @@ | ||
| 2633 | 2633 | const delay = Chat.timer.incrDelay(); |
| 2634 | 2634 | //console.warn("afterPollFetch Chat.e.eMsgPollError",Chat.e.eMsgPollError); |
| 2635 | 2635 | const msg = "Poller connection error. Retrying in "+delay+ " ms."; |
| 2636 | 2636 | if( Chat.e.eMsgPollError ){ |
| 2637 | 2637 | /* Update the error message on the current error MessageWidget */ |
| 2638 | + /* The disadvantage to doing this is that we don't update the timestamp. */ | |
| 2638 | 2639 | Chat.e.eMsgPollError.e.content.innerText = msg; |
| 2639 | 2640 | }else { |
| 2640 | 2641 | /* Set current (new) error MessageWidget */ |
| 2641 | 2642 | Chat.e.eMsgPollError = Chat.reportErrorAsMessage(msg); |
| 2642 | 2643 | //Chat.playNewMessageSound();// browser complains b/c this wasn't via human interaction |
| @@ -2649,10 +2650,16 @@ | ||
| 2649 | 2650 | //console.log("isOkay =",isOkay,"currentDelay =",Chat.timer.currentDelay); |
| 2650 | 2651 | } |
| 2651 | 2652 | }; |
| 2652 | 2653 | afterPollFetch.isFirstCall = true; |
| 2653 | 2654 | |
| 2655 | + /** | |
| 2656 | + Initiates, if it's not already running, a single long-poll | |
| 2657 | + request to the /chat-poll endpoint. In the handling of that | |
| 2658 | + response, it end up will psuedo-recursively calling itself via | |
| 2659 | + the response-handling process. | |
| 2660 | + */ | |
| 2654 | 2661 | const poll = Chat.poll = async function f(){ |
| 2655 | 2662 | if(f.running) return; |
| 2656 | 2663 | f.running = true; |
| 2657 | 2664 | Chat._isBatchLoading = f.isFirstCall; |
| 2658 | 2665 | if(true===f.isFirstCall){ |
| @@ -2665,27 +2672,30 @@ | ||
| 2665 | 2672 | We manager onerror() results in poll() using a |
| 2666 | 2673 | stack of error objects and we delay their handling by |
| 2667 | 2674 | a small amount, rather than immediately when the |
| 2668 | 2675 | exception arrives. |
| 2669 | 2676 | |
| 2670 | - This level of indirection is to work around an | |
| 2671 | - inexplicable behavior from the F.fetch() connections: | |
| 2672 | - timeouts are always announced in pairs of an HTTP 0 and | |
| 2673 | - something we can unambiguously identify as a timeout. When | |
| 2674 | - that happens, we ignore the HTTP 0. If, however, an HTTP 0 | |
| 2675 | - is seen here without an immediately-following timeout, we | |
| 2676 | - process it. | |
| 2677 | + This level of indirection is to work around an inexplicable | |
| 2678 | + behavior from the F.fetch() connections: timeouts are always | |
| 2679 | + announced in pairs of an HTTP 0 and something we can | |
| 2680 | + unambiguously identify as a timeout. When that happens, we | |
| 2681 | + ignore the HTTP 0. If, however, an HTTP 0 is seen here | |
| 2682 | + without an immediately-following timeout, we process | |
| 2683 | + it. Attempts to squelch the HTTP 0 response at their source, | |
| 2684 | + in F.fetch(), have led to worse breakage. | |
| 2677 | 2685 | |
| 2678 | 2686 | It's kinda like in the curses C API, where you to match |
| 2679 | - ALT-X by first getting an ALT event, then a separate X | |
| 2680 | - event, but a lot less explicable. | |
| 2687 | + ALT-X by first getting an ESC event, then an X event, but | |
| 2688 | + this one is a lot less explicable. (It's almost certainly a | |
| 2689 | + mis-handling bug in F.fetch(), but it has so far eluded my | |
| 2690 | + eyes.) | |
| 2681 | 2691 | */ |
| 2682 | 2692 | ()=>{ |
| 2683 | 2693 | if( Chat.aPollErr.length ){ |
| 2684 | 2694 | if(Chat.aPollErr.length>1){ |
| 2685 | 2695 | //console.warn('aPollErr',Chat.aPollErr); |
| 2686 | - if(Chat.aPollErr[1].name='timeout'){ | |
| 2696 | + if(Chat.aPollErr[1].name==='timeout'){ | |
| 2687 | 2697 | /* mysterious pairs of HTTP 0 followed immediately |
| 2688 | 2698 | by timeout response; ignore the former in that case. */ |
| 2689 | 2699 | Chat.aPollErr.shift(); |
| 2690 | 2700 | } |
| 2691 | 2701 | } |
| 2692 | 2702 |
| --- src/fossil.page.chat.js | |
| +++ src/fossil.page.chat.js | |
| @@ -2633,10 +2633,11 @@ | |
| 2633 | const delay = Chat.timer.incrDelay(); |
| 2634 | //console.warn("afterPollFetch Chat.e.eMsgPollError",Chat.e.eMsgPollError); |
| 2635 | const msg = "Poller connection error. Retrying in "+delay+ " ms."; |
| 2636 | if( Chat.e.eMsgPollError ){ |
| 2637 | /* Update the error message on the current error MessageWidget */ |
| 2638 | Chat.e.eMsgPollError.e.content.innerText = msg; |
| 2639 | }else { |
| 2640 | /* Set current (new) error MessageWidget */ |
| 2641 | Chat.e.eMsgPollError = Chat.reportErrorAsMessage(msg); |
| 2642 | //Chat.playNewMessageSound();// browser complains b/c this wasn't via human interaction |
| @@ -2649,10 +2650,16 @@ | |
| 2649 | //console.log("isOkay =",isOkay,"currentDelay =",Chat.timer.currentDelay); |
| 2650 | } |
| 2651 | }; |
| 2652 | afterPollFetch.isFirstCall = true; |
| 2653 | |
| 2654 | const poll = Chat.poll = async function f(){ |
| 2655 | if(f.running) return; |
| 2656 | f.running = true; |
| 2657 | Chat._isBatchLoading = f.isFirstCall; |
| 2658 | if(true===f.isFirstCall){ |
| @@ -2665,27 +2672,30 @@ | |
| 2665 | We manager onerror() results in poll() using a |
| 2666 | stack of error objects and we delay their handling by |
| 2667 | a small amount, rather than immediately when the |
| 2668 | exception arrives. |
| 2669 | |
| 2670 | This level of indirection is to work around an |
| 2671 | inexplicable behavior from the F.fetch() connections: |
| 2672 | timeouts are always announced in pairs of an HTTP 0 and |
| 2673 | something we can unambiguously identify as a timeout. When |
| 2674 | that happens, we ignore the HTTP 0. If, however, an HTTP 0 |
| 2675 | is seen here without an immediately-following timeout, we |
| 2676 | process it. |
| 2677 | |
| 2678 | It's kinda like in the curses C API, where you to match |
| 2679 | ALT-X by first getting an ALT event, then a separate X |
| 2680 | event, but a lot less explicable. |
| 2681 | */ |
| 2682 | ()=>{ |
| 2683 | if( Chat.aPollErr.length ){ |
| 2684 | if(Chat.aPollErr.length>1){ |
| 2685 | //console.warn('aPollErr',Chat.aPollErr); |
| 2686 | if(Chat.aPollErr[1].name='timeout'){ |
| 2687 | /* mysterious pairs of HTTP 0 followed immediately |
| 2688 | by timeout response; ignore the former in that case. */ |
| 2689 | Chat.aPollErr.shift(); |
| 2690 | } |
| 2691 | } |
| 2692 |
| --- src/fossil.page.chat.js | |
| +++ src/fossil.page.chat.js | |
| @@ -2633,10 +2633,11 @@ | |
| 2633 | const delay = Chat.timer.incrDelay(); |
| 2634 | //console.warn("afterPollFetch Chat.e.eMsgPollError",Chat.e.eMsgPollError); |
| 2635 | const msg = "Poller connection error. Retrying in "+delay+ " ms."; |
| 2636 | if( Chat.e.eMsgPollError ){ |
| 2637 | /* Update the error message on the current error MessageWidget */ |
| 2638 | /* The disadvantage to doing this is that we don't update the timestamp. */ |
| 2639 | Chat.e.eMsgPollError.e.content.innerText = msg; |
| 2640 | }else { |
| 2641 | /* Set current (new) error MessageWidget */ |
| 2642 | Chat.e.eMsgPollError = Chat.reportErrorAsMessage(msg); |
| 2643 | //Chat.playNewMessageSound();// browser complains b/c this wasn't via human interaction |
| @@ -2649,10 +2650,16 @@ | |
| 2650 | //console.log("isOkay =",isOkay,"currentDelay =",Chat.timer.currentDelay); |
| 2651 | } |
| 2652 | }; |
| 2653 | afterPollFetch.isFirstCall = true; |
| 2654 | |
| 2655 | /** |
| 2656 | Initiates, if it's not already running, a single long-poll |
| 2657 | request to the /chat-poll endpoint. In the handling of that |
| 2658 | response, it end up will psuedo-recursively calling itself via |
| 2659 | the response-handling process. |
| 2660 | */ |
| 2661 | const poll = Chat.poll = async function f(){ |
| 2662 | if(f.running) return; |
| 2663 | f.running = true; |
| 2664 | Chat._isBatchLoading = f.isFirstCall; |
| 2665 | if(true===f.isFirstCall){ |
| @@ -2665,27 +2672,30 @@ | |
| 2672 | We manager onerror() results in poll() using a |
| 2673 | stack of error objects and we delay their handling by |
| 2674 | a small amount, rather than immediately when the |
| 2675 | exception arrives. |
| 2676 | |
| 2677 | This level of indirection is to work around an inexplicable |
| 2678 | behavior from the F.fetch() connections: timeouts are always |
| 2679 | announced in pairs of an HTTP 0 and something we can |
| 2680 | unambiguously identify as a timeout. When that happens, we |
| 2681 | ignore the HTTP 0. If, however, an HTTP 0 is seen here |
| 2682 | without an immediately-following timeout, we process |
| 2683 | it. Attempts to squelch the HTTP 0 response at their source, |
| 2684 | in F.fetch(), have led to worse breakage. |
| 2685 | |
| 2686 | It's kinda like in the curses C API, where you to match |
| 2687 | ALT-X by first getting an ESC event, then an X event, but |
| 2688 | this one is a lot less explicable. (It's almost certainly a |
| 2689 | mis-handling bug in F.fetch(), but it has so far eluded my |
| 2690 | eyes.) |
| 2691 | */ |
| 2692 | ()=>{ |
| 2693 | if( Chat.aPollErr.length ){ |
| 2694 | if(Chat.aPollErr.length>1){ |
| 2695 | //console.warn('aPollErr',Chat.aPollErr); |
| 2696 | if(Chat.aPollErr[1].name==='timeout'){ |
| 2697 | /* mysterious pairs of HTTP 0 followed immediately |
| 2698 | by timeout response; ignore the former in that case. */ |
| 2699 | Chat.aPollErr.shift(); |
| 2700 | } |
| 2701 | } |
| 2702 |