Project

General

Profile

Bug #10995

Fatal error: WContainerWidget: error parsing: undefined

Added by Alexey Mukhin about 2 months ago. Updated 3 days ago.

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

0%

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 about 2 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 3 days ago

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

Updated by Roel Standaert 3 days ago

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

Updated by Roel Standaert 3 days ago

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

Also available in: Atom PDF