Inexplicable error on Chrome

[John Robin Dove]

Hi Clifton,
I have spent hours trying to understand what's happening. I show the second page of my tbk in an iframe using pgGotoURL(). No problem with Firefox:

but in Chrome this happens:

I have tried all kinds of things including console.log(iframe.contentWindow.scrollY) but it returns 0 as it should. This only started happening this morning. Have you any suggestions, please?
John

[Clifton]

When looking at the Chrome page, it looks like the application is hanging while loading the page elements. It could be just one item causing the hang, but something is causing Chrome to have trouble loading the elements at the top of your page.

To troubleshoot this, start by disabling elements one at a time until Chrome loads successfully. There could a poorly formed function that is causing this (that would be my guess). Chrome may be expecting something that is just not there and a function is calling for it. No error is showing either because, there may be a try/catch block preventing the error from being seen by the developer.

When once you find the error, it is quite likely that both Firefox and Chrome are having the same problem, but Firefox is handling it more transparently, but that doesn't mean it is not there. You might check Edge, but I am quite sure Edge will behave like Chrome as it is Chromium based.

You can usually explore loading errors like this by commenting out your XML until the page loads. Then begin commenting out sub-sections in those sections to isolate the error condition until it become obvious what is happening.

While this looks like a BIG problem, it will likely come down to just one function or element. If it was more than that, then both browsers would be struggling to load the page.

[John Robin Dove]

It turns out it's probably nothing nothing to do with my code. I would like to have the same type of TB editable field (which is exported as a textarea) on page 2 as on page 1. This is quite important because I have not found a way to select text programmatcically without using a textarea. If I use Firefox everything goes to plan but in Chrome the page is not displayed correctly. If you select behavior: lock the text etc. the problem disappears. I'm hoping you can reproduce this on your system. I have stripped out all unnecessary code and put a zip here: https://www.mediacours.com/tb_examples/textAreaProblem.zip. Please take a look when you have time.
Thanks
John

[Clifton]

I've attached a modified version of your test which now works on Firefox, Chrome, and Edge.

What was the issue?

• Your use of mergeTBObjects() may have been a bit too aggressive. I just made the recorder group the merge container and that was sufficient.
• A bigger issue may have been the fact that the page you were loading was not using its own background. Pages loaded into containers should be as unique as possible from the rest of the book. I even flag them skipNavigation = true to make sure nothing about these dialog pages can interfere with other things. So I created a new background for page "text2" and sized it accordingly as well as the "controls" field on page "test1" which serves as the container. I removed the field "recContainer" as it was no longer needed; and of course, fixed some of the code to point to "recorder" instead of "recContainer".
• I also found a few errors in your XML.
  For example you have a comment in the your XML "//---------------------sharedActions------------------------". This is illegal and can cause problems, though I didn't see that as the problem in this case. Comments in XML should be defined like this: <!-- This is my comment -->
  Other errors were corrected, but I cannot say these were the problem either. Nevertheless, I wanted to make sure all the code was not causing problems.

Of course, I cannot say whether this will solve anything as far as the textarea issues you described. But at least the page is loading properly.

[John Robin Dove]

Hi Clifton,
Thank you very much for all your corrections. I have modified my files using all your suggestions. Unfortunately the problem is still not solved but your version has allowed me to identify what's causing it. Its the size of the background (which is now the second background). If I use the size in the test tbk that I sent, Chrome still fails to display the page correctly. If I use your size (13665,6120 in the tbk), there is no error. The problem is that I want this background to be at least as big as the first background because I don't know how long the text in field "sentence" will be. I plan to adjust everthing to adapt to the size of this text. I don't want to use a scollbar because that's not compatible with the 'animated reading system'.
John
UPDATE Whatever is going wrong happens when the page is exported. I have tried to resize page and background in the xml file but so far I have not succeeded. I have also tried making the the background slightly larger before export but this also fails.

[Clifton]

When resizing the page for display, try using setPageContentPosition() before using pgGotoURL().
In most cases, it shouldn't really matter if elements are bigger than the page.

[John Robin Dove]

Thanks. setPageContentPosition() allows me to do what I want using the second page background size that you set but I wasn't able to use it in the way you suggested, at least I don't think so. Here is the script of a test button:

Code: Select all

 <function name="myClick" event="click" params="" useTB="true">
  <![CDATA[
  sharedActions.myHeight += 50; //sharedActions.myHeight is 400. In the final version the height will depend on the height of field 'sentence' in the iframe which is set by using the hidden field 'sentence2' because height: auto is not available on a textarea. Normally a textarea will not respond to height = n either, so someone, either you or a TB developer, must have written some clever code to convert height to rows.
  tbfunction_pgTBObjSet("controls", "height", sharedActions.myHeight); //tb field containing page 'recorder2'.
  tbfunction_pgTBObjSet("recorderPanel", "height", sharedActions.myHeight + 50);//draggable field grouped with field 'controls'.
  tbfunction_pgExecuteRemote("controls", "tbfunction_setPageContentPosition", [0, 0]);
  console.log(sharedActions.myHeight)
  ]]>
  </function>

If tbfunction_setPageContentPosition", [0, 0]) is not included, the page content rides down the page every time the height is increased. I have no idea why but I guess that doesn't matter because it does exactly what I need. As you say, the height of the page does not seem to matter and the background always remains visible and complete.
It so happens that this is the first time I have used a tbk with more than one page. My previous project contained around 25 tbk files all with only one page, so I haven't much experience with extra pages.

[Clifton]

When using setPageContentPosition() in a dialog box or frame, you will need to specify an offset left and top page position or ToolBook will always attempt to auto center using ToolBook's internal function. While this is fine for the main window page, it doesn't play well with dialog windows. So specifying left = 0 and top = 0 will anchor the page to the top left corner of the dialog window or container object and it will disable ToolBook's auto-centering script. The best place to run this function is in the <config> section of the XML file that loads with the page that will be displayed in the dialog windows or container.

<config>
    <setPageContentPosition>
        { left : 0, top : 0, width : [myWidth], height : [myHeight] }
    </setPageContentPosition>
</confi>

You can also execute this function on page load in the Actions Editor. If your width and height values are calculated based on other factors, then you may have no choice but to execute setPageContentPosition() elsewhere in your XML file. The next best place may be in an <exeJavascriptDirect> tag of the <config> section, or in an onload function defined in the <page> section.
 

[John Robin Dove]

Hi Clifton,
I am still having problems with this in Chrome. However, if I use the version that you compiled from the selection_test_modified.zip above, the problem disappears. I mean I have put all my code into the two xml files test1.xml and test2.xml and used the selection_test.tbk that you sent and miraculously everything is OK. It seems to suggest that it might be my patched version of Toolbook 9.01 that is to blame.
John

UPDATE (more inexplicable stuff!)
I am continuing to progress using the tbk file you sent. I've resaved it under a different name and it's still OK so I'm not so sure now that my Toolbook 9.01 was causing the (re)sizing error. Anyway it doesn't matter as long as it works. A similar story with this:

Code: Select all

 <OB2-4>
  <function name="myClick" event="click" params="" useTB="true">
  <![CDATA[
  let wordNo = tbfunction_pgTBObjGet("OB2-3", "text");
  wordNo = wordNo * 1;
  wordNo -= 1;
  let ctr = top.sharedActions.ctr;
  ctr -= 1;
    if (wordNo > 0)
    {
      if (wordNo == 1)
      {
      tbfunction_pgTBObjSet("OB2-4", "enabled", false);
      }
    tbfunction_pgTBObjSet("OB2-2", "enabled", true);
    let word = sharedActions.getWord(wordNo);
    tbfunction_pgTBObjSet("OB2-5", "text", word);
    const unit = top.sharedActions.speeds[ctr][0];
    let speed = top.sharedActions.speeds [ctr] [wordNo];
    speed *= unit
    speed = speed + " ms";
    tbfunction_pgTBObjSet("OB2-6", "text", speed);
    //tbfunction_pgTBObjSet("OB2-3", "text", wordNo);  //I don't know why this fails.
    let obj = gTBo("OB2-3", "objRef");
    obj.innerHTML = wordNo;
    }
  ]]> 
  </function>     
  </OB2-4>

I've tried changing the name of the field, moving it out of the group etc. but nothing seems to fix it. As the workaround always succeeds, it doesn't really matter.