Bug #7811

"Wt: invalid ackId" for a certain setting.

Added by Apivan Tuntakurn over 2 years ago. Updated about 1 year ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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.


main.cpp (2.96 KB) main.cpp Apivan Tuntakurn, 11/02/2020 10:02 AM

Updated by Apivan Tuntakurn over 2 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 2 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 2 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 2 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 2 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 2 years ago

  • Status changed from Implemented @Emweb to Resolved

It's on GitHub now (master branch).


Updated by Apivan Tuntakurn about 2 years ago

Thank you very much sir


Updated by Roel Standaert over 1 year ago

  • % Done changed from 0 to 100

Updated by Roel Standaert about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF