Project

General

Profile

Actions

Bug #10995

closed

Fatal error: WContainerWidget: error parsing: undefined

Added by Alexey Mukhin about 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Roel Standaert
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

Actions #1

Updated by Roel Standaert about 2 years 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.

Actions #2

Updated by Roel Standaert almost 2 years ago

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

Updated by Roel Standaert almost 2 years ago

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

Updated by Roel Standaert almost 2 years ago

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

Actions #5

Updated by Roel Standaert almost 2 years ago

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

Updated by Roel Standaert almost 2 years ago

  • Status changed from Implemented @Emweb to Resolved
Actions #7

Updated by Roel Standaert almost 2 years ago

  • Target version changed from 4.9.0 to 4.8.3
Actions #8

Updated by Roel Standaert almost 2 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF