I’ve made a gallery widget which we have used extensively in iBooks without problems. However, in the attached iBooks file, the widget acts strangely. On each slide there are text entry fields which enable users to enter answers while they scroll through the slides. These are grouped as a symbol. On the first slide, only when the widget activates, the symbol jumps to the top of the scene under the image. If you go to the second scene and come back, all is well.
I’ve attached the Hype project this is taken from. I’ve had to remove some images to keep the file size low.
I am not taking it as I don’t develop iBooks-Widgets but I looked at your code and my huch would be that it has to todo with the load() method. There is no direct manipulation going on but maybe some of the classes you assign reset the position data. Have you tried excluding class interaction with a empty load method to see if the problem is Hype related or rather coming from CSS? Also you are using the standard CSS position method (top, left) rather then the hardware accelerated CSS translation (see Document-Panel). I guess this is duo to you using jQuery or iBooks? Two hints… hope they help!
I noticed that the function that puts the dots and arrows on the first scene wasn’t running properly. The arrow was there, but no dots. As soon as I added a class and a CSS top position to the symbol in the load function to force it to stay where I wanted it, all was good.
No idea why it was being forced up though as no styling was being applied to anything in the symbol on load so this is a work around not really a solution the problem.
It seemed to be having issues with the form tag from what I could tell, but without a lot of debugging in that environment I couldn’t really see. So if you got it working I’d be curious about looking at a full diff of what you did!
you’re right. It seems to be an issue with adding a textarea or input into the existing inputs. I can add in other html and even give it the same class, but whenever I add textarea or change it to input, the jump occurs.
The version I ‘fixed’ was a workaround. It didn’t style the dots or arrows although it added the dots correctly, but given that it did allow the form to remain in place, it was good enough for the time being and against the deadline we’re working to. But if I can have both working, that would be ideal.
Seems strange that simply adding input to the inner html of each input would cause the entire symbol to move - and then only on the first scene on load.
I think execution was halting at some point, so styles were not being applied. I tried putting items in a try/catch block, but that did not help… in fact if I added debugging messages they would not even be executed ahead of the line that set the inner HTML, which was quite puzzling. There are a few common causes I ruled out, but without a good debugging environment I came up empty as to the root issue.
Attached are two gallery widgets with text inputs that both use symbols containing clear buttons on the front page. In the P20 one, the button jumps to the top left of the widget when it plays on an iPad. This is what we’d expect from our earlier discussion above.
However, in the second widget, P74 which is a clone of the other, the button stays in place on the iPad. I am unsure why and I therefore don’t know how to get the P20 to function properly.
I thought maybe as we have a working version now, one of you might be able to see what I can’t i.e. what’s making the difference between the two.
At this point I suspect it is some sort of bug/conflict with iBooks. There doesn’t seem to be any environment that can replicate this issue otherwise – I even launched Dashboard to try the widget in its “native” environment and couldn’t repro.
iBooks used to have some way to bring up the Web Inspector, but this no longer works (at least as of the earliest I can easily test is on macOS 10.10), so it is difficult to get more at the root.
That said, it does look like the top/left positioning is being set to 0px. One workaround I found is that if you uncheck Position with CSS left/top in the Document Inspector, the positioning will be correct since instead it uses CSS transforms for positioning rather than the left/top attributes. (this may be an invalid workaround if you are using any of the jquery lib for setting this position)
Another workaround I found was that if you place the Hype document within an iframe, it seems to insulate the document from whatever is causing the issue. The steps to do this would be:
Export the widget
Select in the finder, and control-click and choose “Show Package Contents”
Duplicate index.html and rename the copy to index2.html
Open the original index.html and change it to code that references index2.html as an iframe. It would look something like:
that’s very helpful thanks Jonathan. Unchecking Position with CSS left/top is the simplest workaround which prevented this unwanted behaviour although we appreciated seeing how you can create an iframe in iBooks.
I’m not sure if this is a related issue or not, but I thought I’d post this here in case it is. The gallery widget that we’ve been working with has been fine except for that symbol jump issue. However, we’ve noticed something else which has just started occurring recently and does not seem to be predictable.
In the attached project, we’re noticing that when the widget activates in iBooks, often (not always) the text input on the first scene disappears. It appears when you go to another scene and then return, but then it disappears if you reset the widget by hitting the clear button.
I’ve also noticed that text inputs on subsequent scenes slide in but then seem to jump up a pixel or two when the scene stops animating in. Might be related although I’m not sure how at the moment.
Working more on this has revealed that there seems to be a connection between there being an image on the first scene and the disappearing text boxes and jumping symbol.
If we take a widget that is working perfectly and dump an image into any scene, this causes the text boxes to disappear only on the first scene. Tapping to another scene and back again restores the Scene 1 text boxes. I’ve attached two projects that illustrate this. Note that this only happens when the widget activates in iBooks so I’ve added the iBooks file, too. It doesn’t happen when previewed in Safari.
We’ve narrowed the bug down to the line of code below and it seems to make no difference where we place this in load(). Nor can figure out why the presence of an image should make this code problematic. It also happens if we load the image using code instead of simply drag and drop to the canvas.
$('.box').each(function() {
var counter = $('.box').index($(this)) + 1;
// removing the line below stops the bug occurring
$(this).html('<textarea id="textField' + counter + '" class="text-input" tabindex="' + counter + '" autocapitalize="none" oninput="saveText()">');
});
We’re also mystified by the fact that if we throw an alert at the end of the load() code, once we clear the alert in the iBook, the page loads fine even if there’s an image. Why an alert should prevent the bug from occurring makes no sense to us. Obviously, we don’t want to put an alert on every widget.
My guess would be that it is related, but this is quite a baffling issue. I’d guess it is either some javascript name collision, perhaps with iBooks HTML code itself, that is acting in wildly different ways, or a browser bug that only manifests in specific iBook environmental conditions along with your code.
I did try the iframe method from above, but that didn’t actually fix the problem. So perhaps not? I’m really at a loss.
The other item I tried was removing the <input class="text-input"> from the Inner HTML of your “textField” element since this would be replaced by the textarea anyways. This seemed to work for me. So perhaps the issue has to do with that in some way? Can you give that a try and see if it helps?
(I did also change the box to have a white background color, so it looks more like the eventual text area)