[E, P] (Court Bug) Characters Bug v5-Converted Positions

[Enthalpy]

I can't reproduce this bug anymore, even on the open-source version, which couldn't possibly have changed. So, Chrome fixed this one itself?

If anybody else does see this, just post here with a specific example.

[Thatonejimmy]

this is happening to me too. want proof?
http://prntscr.com/7gpjxq
there's your proof.

[newfieshark]

Um, Im having trouble getting the benches to align properly. Instead it looks like a blur and one side of the bench and I can't fix it.

[kwando1313]

Are you on Chrome? This seems to be an odd glitch on Chrome right now... Try using Firefox instead for now, and it should work.

[Enthalpy]

I still can't reproduce this, even on Chrome.

Can you two tell me what browser you're using, and what Operating System you're using?

[JacenBoy]

I got it on two different computers, both running Chrome on Windows 7.

[Enthalpy]

For some reason, I can reproduce this now on either OS, but whether or not I'll actually see the bug is random.

I'll hope to take a closer look at this soon (including with an actual test case), now that it seems to exist after all.

EDIT 01: Demo trial created. In the editor, behavior in the screen editor and screen preview for a given frame is inconsistent - sometimes the glitch is displayed, and other times it is not. Mouseover sometimes converts from one to the other, but this behavior is inconsistent.

For clarification, "screen preview for a given frame" refers to the HMTL element with class 'display_engine_screen half-size'.

[drvonkitty]

Yup, I'm getting this same exact bug. Running Chrome and Windows 8.1, not a converted trial.

[Enthalpy]

Demo trial updated with a new find - there's no smooth scrolling when this glitch occurs, even if smooth scrolling is enabled.

I'm going to be trying a new method to try and solve this one...

EDIT: There's been some progress. Although source specifies that display_engine_place's width should be 1296 for court frames, hovering over the relevant line of code using Chrome's developer tools sometimes gives only 256. I say "sometimes" because the appearance of the glitch is still inconsistent, and when it works properly, the dev tools give the expected 1296. My intuition is that the order in which some setTimeouts run may be at play, but I'll keep investigating!

Also, this bug only appears if a character is set... Hmm...

EDIT: And when I try to examine the bug using Chrome breakpoints... The bug vanishes.

EDIT: Confirmed independence of foreground objects. The demo case is being amended accordingly, to reduce the complexity of what's going on...

EDIT: I found a fix, but it's... weird. Removing width: 100% in .display_engine_place > * fixes the glitch. Why it does this, I have no idea.

[Chimp]

I think that as a replacement setting, if the court situation gets out of hand, you can try getting your own files of the benches...say, photos?

[Enthalpy]

The problem isn't with the pictures: it's that Chrome (for some reason) doesn't understand when we try to tell it how big the picture is.

You'll have to switch to Firefox until this is fixed.

[drvonkitty]

I have a different version of this bug, same OS and non-converted trial as I specified before, ever since the update to the player. Now, all courtroom positions default to left aligned, making Chrome unusable for me. Firefox works fine, in contrast.

[Unas]

Ah, I should have seen that coming. It's probably the same bug, just one step further.

Enth, since you were able to reproduce the original bug, you should be able to reproduce this one as well I guess.
It looks like your fix is indeed enforcing the picture dimensions to be correct, but that is not taken into account by the setScreenPosition method. The method still sees a 256px wide scene - and right align and left align on a 256px scene are the same.

I guess Chrome is returning the wrong value in self.place_display.render.clientWidth .
Possibly because it didn't have time to refresh the display since applying the enforced dimensions, and therefore the display dimension (clientWidth) remains unchanged... At the level of your previous fix, you could try to change
"loadCompleteTrigger()"
with
"window.setTimeout(loadCompleteTrigger, 0)"
It should allow a reflow of the page after your fix is applied and before running the next part.

It's not pretty at all though and may cause some lag, at some point I guess I'll have to investigate the root cause. of why Chrome is failing like that in the first place, and fix that deeper in the display engine...

[Enthalpy]

Funny you should mention that. I found some time to probe the bug a bit deeper the weekend after I submitted the fix, and I found that the problem involved returning the incorrect clientWidth value... But I wasn't able to ascertain this directly. Whenever I tried to print the value to the console, it gave the correct value, and the bug disappeared!

As another test that could be important, I tried setting the width of the black background to be 10 pixels shorter than the viewport, and inserting a defense lobby background before going to the courtroom. Sure enough, the defense lobby scrolling bug happened if and only if the defense lobby was squeezed to 246 pixels - the width of the black background.

There's one other test that... I don't know how to interpret. One of my attempts to find the root cause of the bug was to strip out every unnecessary function the editor went through. As part of this, I tried removing the wrapping of trial_data by a PartialBufferWrapper, but that increased the probability of the glitch appearing. It was still random, but now just more likely to occur. How does that work?!

Like I said in my fix notes, that was intended as a quick and dirty fix, and a full investigation is my top priority for the open-source project. After this week, I have about a full month free of college classes, so I should have the time to fully crack this one.

[CaptainJbeans]

Hello, I've been experiencing a bug that has really messed with my trial when I was creating it.
Sometimes, when I right-aligned the courtroom to show the prosecution's bench, then I added a prosecutor (i.e. Edgeworth), and right aligned him, saved, and playtested my trial, sometimes the defense bench would switch to be left-aligned, while keeping Edgeworth at his original position, making him malformed (I love when I say that word). I found the only way to fix this glitch is to hit the save button multiple times and after that, pressing multiple tabs and then playtesting again, although it keeps happening randomly, almost every time I save and playtest. Does anybody have a hint on what the heck is happening to the editor?
*edit* Also, the smooth motion will not play if the bench is left-aligned and Edgeworth is right-aligned, even if the box for smooth motion is checked.