Bug #7811
closed"Wt: invalid ackId" for a certain setting.
100%
Description
On our complex web application, We have a use case thatoccasionally produces "Wt: invalid ackId" and freeze the client on some computer.
So, I created the isolated program that always produces the invalid ackId and attech it here. (main.cpp)
However, I do not confirm whether the isolated program could freeze the client or not.
The following are factors for invalid ackID
- It must have high cpu intensive javascript code
- It must use Wt’s javascript layout
- It must have at least one setLayoutSizeAware(true) widget. Note that the WPaintedWidget uses setLayoutSizeAware(true) by default. And for our situation, it is not avoidable.
I am not sure if this is really a bug or just bad use case. In case that it is a bad use case, do you have any suggestion?
Workaround: using WebSocket solves the problem. But it is not an option for our case.
Files
Updated by Apivan Tuntakurn over 3 years ago
Reproducible on 4.1.1 and 4.2.2. Did not test with latest wt yet. But It think it is very likely reproducible.
Updated by Apivan Tuntakurn over 3 years ago
On * src/web/skeleton/Wt.js:function propagateSize(element, width, height)* , warping the emit signal inside setTimeout(0) seems to fix the problem. The ackid increments correctly. But I am not sure if it will cause problem elsewhere.
Updated by Apivan Tuntakurn over 3 years ago
Calling this as soon as possible solves invalid ackid.
this->doJavaScript(R"( Wt.p.propagateSize = function(t,i,e){-1==i&&(i=t.offsetWidth),-1==e&&(e=t.offsetHeight),void 0!==t.wtWidth&&t.wtWidth==i&&void 0!==t.wtHeight&&t.wtHeight==e||(t.wtWidth=i,t.wtHeight=e,i>=0&&e>=0&&window.setTimeout(()=>{ Wt.emit(t,"resized",Math.round(i),Math.round(e))},0))};)");
Updated by Korneel Dumon about 3 years ago
- Status changed from New to Implemented @Emweb
- Assignee set to Korneel Dumon
- Target version set to 4.5.1
Thanks for the example. The issue occurred when multiple signals are emitted during a server-push update with some amount of time in between.
Updated by Roel Standaert about 3 years ago
- Target version changed from 4.5.1 to 4.6.0
I think I'll keep this for 4.6.0. I'm not confident enough that it's safe to put it in 4.5.1.
Updated by Roel Standaert about 3 years ago
- Status changed from Implemented @Emweb to Resolved
It's on GitHub now (master branch).
Updated by Roel Standaert over 2 years ago
- Status changed from Resolved to Closed