Project

General

Profile

Bug #2793

dynamic layout javascript errors with Wt-3.3.2-rc2 (git version 2nd march)

Added by Stefan Ruppert over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Target version:
Start date:
03/10/2014
Due date:
% Done:

0%

Estimated time:

Description

Hi,

with our myarmbrowser Wt app I get the following error when using our config feature (loading a complete view setting form database) a second time.

Screenshot 1 was taken after loading a configuration setting from database the first time. Selecting another configuration setting from database the error in screenshot 2 occurs.

Note we dynamically change the contents of the "Configuration" WContainerWidget by creating a new WVBoxLayout() widget and replacing the old layout by calling WContainerWidget::setLayout()!

With Wt-3.3.1 this works quite fine.

A working version wt Wt-3.2.3 can be found here: http://myarm.info/fcgi-bin/myarmbrowser.fcgi?cfg=HTTP-CDDB-Sequence&mds=2&apply

Change the combo-box under within the Configuration WGroupBox on the top left side!

Regards,

Stefan


Files

myarmbrowser-config-loaded.png (233 KB) myarmbrowser-config-loaded.png Stefan Ruppert, 03/10/2014 08:06 PM
myarmbrowser-config-loading-error.png (297 KB) myarmbrowser-config-loading-error.png Stefan Ruppert, 03/10/2014 08:06 PM
myarmbrowser-javascript-error.png (227 KB) myarmbrowser-javascript-error.png Stefan Ruppert, 03/11/2014 12:14 PM
#1

Updated by Stefan Ruppert over 7 years ago

To reproduce this bug you can use our test installation at http://arm4.de:81/fcgi-bin/myarmbrowser.fcgi

Hit "Use"-Button in the top middle of the view. And select first one configuration from the "Configuration" combo-box and later a second config!

#2

Updated by Stefan Ruppert over 7 years ago

This URL leads directly to a javascript error: http://arm4.de:81/fcgi-bin/myarmbrowser.fcgi?cfg=HTTP-CDDB-Sequence

with Wt-3.3.1 and Wt-3.2.3 this worked fine!

#3

Updated by Koen Deforche over 7 years ago

  • Status changed from New to Feedback
  • Assignee set to Koen Deforche
  • Target version set to 3.3.2

Hey Stefan,

The problem is caused by the following JavaScript:

Wt3_3_2.$('opls9a3').options[2].style.display='none';
Wt3_3_2.$('opls9a3').options[1].style.display='none';
Wt3_3_2.$('opls9a3').options[0].style.display='none';

The element (a combo box or selection list?) is not rendered. How do you implement this? It could be that the corresponding widget, even though it's been created and part of the widget tree, isn't rendered yet because it's invisible (i.e. part of a hidden widget) and that widget was stubbed (which Wt will do automatically if there is alot of content not yet visible).

To be robust to this, you should use 'WWidget::doJavaScript()' or defer these kind of JavaScript calls until in WWidget::render().

Regards,

koen

#4

Updated by Stefan Ruppert over 7 years ago

Hi Koen,

I use the following code:

void WComboBoxItemHidden(Wt::WComboBox* cb, int item, bool hidden)
{
   if((item>=0) && (item<cb->count()))
   {
      std::string d = hidden ? "'none'" : "'block'";
      std::stringstream ss;
      ss << cb->jsRef() << ".options[" << item << "].style.display=" << d << ";";
      Wt::WApplication::instance()->doJavaScript(ss.str());
   }
}

Is there a difference between Wt::WApplication::instance()->doJavaScript() and WWidget::doJavaScript()?

Regards,

Stefan

#5

Updated by Koen Deforche over 7 years ago

Hey Stefan,

Yes: WWidget::doJavaScript() will defer the JavaScript until the widget is actually rendered.

And I forgot: the ability to make certain combo-box items disabled or hidden seems generally useful. Does that work on all major browsers? We would be happy to implement features like these in the library.

Regards,

koen

#6

Updated by Stefan Ruppert over 7 years ago

Hi Koen,

using WWidget::doJavaScript() seems to work! Thanks!

Disabling an item works in Firefox, Chrome, IE and Opera, Hiding only in Firefox and Chrome. Maybe you can implement a Hidden flag in WStringListModel and the default is to remove the complete option and in Firefox and Chrome you can just set the display attribute to none?

Regards,

Stefan

#7

Updated by Koen Deforche over 7 years ago

  • Status changed from Feedback to Resolved
#8

Updated by Koen Deforche over 7 years ago

Hey,

It sounds like we should then implement disabled, supported as a WAbstractItemModel flag.

Can you file this as a feature request?

Regards,

koen

#9

Updated by Stefan Ruppert over 7 years ago

Hi Koen,

sorry, but I tested the WWidget::doJavaScript() accidently with the Wt 3.3.1 version... And with this version our dynamic layout works fine. I got another error see the attached screenshot.

Hmm, I can't reopen this bug...?!

Regards,

Stefan

#10

Updated by Stefan Ruppert over 7 years ago

Hi,

to reproduce the above error use this URL: http://arm4.de:81/fcgi-bin/myarmbrowser.fcgi?cfg=CDDB-Query-Overview and select "HTTP-arm4sdk" entry fro the Configuration Combobox.

Regards,

Stefan

#11

Updated by Koen Deforche over 7 years ago

  • Status changed from Resolved to InProgress

Hey,

Can you enable in your wt_config.xml ? This would allow me to debug the JavaScript issue.

I do have the feeling that this is indeed something that we broken in calling WContainerWidget::setLayout() to replace an existing layout. We'll try to reproduce to dig this is up in a test-case.

Regards,

koen

#12

Updated by Stefan Ruppert over 7 years ago

Hi,

I digged more into detail and find the code which causes this error: My older implementation of setModus() (#if 1) works and my newer implementation (#else branch) does not work with wt-3.3.2 but works with wt-3.3.1!

#if 1
void SelectionViewWidget::setModus(int i)
{
   if(mModus->modus() != i)
      mModus->setModus(i);

   removeWidget(mStretch);
   removeWidget(mSystemList);
   removeWidget(mApplicationList);
   removeWidget(mTransactionList);
   removeWidget(mUserList);
   removeWidget(mAttributeFilter);

   mConstraints.mModus = i;
   switch(mConstraints.mModus)
   {
   case MO_NOTHING:
      break;
   case MO_SYSTEMS:
      mLayout->addWidget(mSystemList, 0, AlignTop);
      break;
   .......
   case MO_USERS_SYSTEMS:
      mLayout->addWidget(mUserList, 0, AlignTop);
      mLayout->addWidget(mSystemList, 0, AlignTop);
      break;
   }
   if(mConstraints.mModus != MO_NOTHING)
      mLayout->addWidget(mAttributeFilter, 0, AlignTop);
   mLayout->addWidget(mStretch, 1);
}
#else
void SelectionViewWidget::setModus(ModusOperandi i)
{
   if(mModus->modus() != i)
      mModus->setModus(i);

   WVBoxLayout* layout = new WVBoxLayout();
   layout->setContentsMargins(2, 2, 2, 2);
   layout->addWidget(mConfigButtons);
   layout->addWidget(mModus        );

   mConstraints.mModus = i;
   switch(mConstraints.mModus)
   {
   case MO_NOTHING:
      break;
   case MO_SYSTEMS:
      layout->addWidget(mSystemList);
      break;
   ........
   case MO_USERS_SYSTEMS:
      layout->addWidget(mUserList);
      layout->addWidget(mSystemList);
      break;
   }
   if(mConstraints.mModus != MO_NOTHING)
      layout->addWidget(mAttributeFilter);
   layout->addWidget(mStretch, 1);
   setLayout(layout);
}
#endif
#13

Updated by Stefan Ruppert over 7 years ago

Hi,

I turned debug-option on!

Regards,

Stefan

#14

Updated by Koen Deforche over 7 years ago

Hey stefan,

Great. Thanks. I think I know what's going on. I'll reproduce this here, and get it fixed ASAP (for 3.3.2).

Regards,

koen

#15

Updated by Koen Deforche over 7 years ago

  • Status changed from InProgress to Feedback

Hey,

Actually, I wasn't able to reproduce this, although the symptom was quite clear. It's actually a 'regression' only in the sense that we fixed an issue that now is revealing this.

So I did commit a change that should either fix the issue altogether, should at least address the symptoms, or will simply fail on a next problem that indicates there's something more fundamentally wrong that we're not seeing. In either case, it would be great if you could try latest git.

Regards,

koen

#16

Updated by Stefan Ruppert over 7 years ago

Hi Koen,

latest git version seems to fix our problem.

Thanks,

Stefan

#17

Updated by Koen Deforche over 7 years ago

  • Status changed from Feedback to Resolved

Great!

Koen

#18

Updated by Koen Deforche over 7 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF