Project

General

Profile

Bug #10995

Fatal error: WContainerWidget: error parsing: undefined

Added by Alexey Mukhin 6 months ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
10/06/2022
Due date:
% Done:

100%

Estimated time:

Description

Hi, I have a problem with my application, it destroys after certain actions with the following errors:

1712 [2022-Oct-06 15:51:18.046] 179168 [/ YSMN1DEmShN9BxQm] [error] "Wt: error during event handling: WContainerWidget: error parsing: undefined"                                       
1713 [2022-Oct-06 15:51:18.047] 179168 [/ YSMN1DEmShN9BxQm] [error] "Wt: fatal error: WContainerWidget: error parsing: undefined"

I use one WTabWidget inside of another and I use setOverflow(Wt::Overflow::Visible) for them.
wt_config.xml has the reload-is-new-session option set to false.

Steps to reproduce are:

  1. Refresh page
  2. Click on checkbox

After that session is destroyed. If I don't use setOverflow(Wt::Overflow::Visible), session is not destroyed and everything works as expected.
Tested on versions 4.7.3, 4.8.1

Here's minimal example:

  auto containerOuterTab = std::make_unique<WContainerWidget>();
  auto containerInnerTab = std::make_unique<WContainerWidget>();

  auto tabWidgetOuter = this             ->addNew<WTabWidget>();
  auto tabWidgetInner = containerOuterTab->addNew<WTabWidget>();

  containerInnerTab->addNew<WCheckBox>("Checkbox")->changed().connect([this]() { std::cout << "Checkbox changed" << std::endl; });

  tabWidgetOuter->setOverflow(Wt::Overflow::Visible);
  tabWidgetOuter->addTab(std::move(containerOuterTab), "Outer tab");

  tabWidgetInner->setOverflow(Wt::Overflow::Visible);
  tabWidgetInner->addTab(std::move(containerInnerTab), "Inner tab");

Files

tabs.png (5.82 KB) tabs.png Alexey Mukhin, 10/06/2022 03:05 PM
0001-WT-10995-fix-WContainerWidget-s-wtEncodeValue-not-su.patch (3.15 KB) 0001-WT-10995-fix-WContainerWidget-s-wtEncodeValue-not-su.patch Roel Standaert, 11/30/2022 04:37 PM
#1

Updated by Roel Standaert 6 months ago

  • Target version set to 4.9.0

We'll take a look at this. We shouldn't let the application throw an exception on that error in the first place, but it should also be interesting to see how this happens, so hopefully, we'll be able to reproduce your issue.

#2

Updated by Roel Standaert 4 months ago

  • Status changed from New to InProgress
  • Assignee set to Roel Standaert
#3

Updated by Roel Standaert 4 months ago

  • Status changed from InProgress to Review
  • Assignee changed from Roel Standaert to Korneel Dumon
#4

Updated by Roel Standaert 4 months ago

The issue should be resolved with the attached patch (currently in review for inclusion into version 4.8.3).

#5

Updated by Roel Standaert 3 months ago

  • Status changed from Review to Implemented @Emweb
  • Assignee changed from Korneel Dumon to Roel Standaert
  • % Done changed from 0 to 100
#6

Updated by Roel Standaert 3 months ago

  • Status changed from Implemented @Emweb to Resolved
#7

Updated by Roel Standaert 3 months ago

  • Target version changed from 4.9.0 to 4.8.3
#8

Updated by Roel Standaert 3 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF