slide-drive
slide-drive copied to clipboard
Slide Markers On Audio Control Are A Mess
The blue background behind/between the white indicators on the timeline overflows to the next line. (This does not happen at lower-than-default zoom levels.)
Perhaps summing up the percents causes something to be rounded up too far, or perhaps the spacers are throwing things off.
I just noticed this particular mistake, but I don't think it's a new regression. I'll check when I fix it.
Ensure that these markers are fixed in general, not just this specific misbehaviour.
This is a brand new regression. It started in f9a8eaabe7dba9c8f98bbae65216de94551d67eb when I started incrementing count
again (I'd previously accidentally deleted the line responsible). The bug is caused by this code:
// such a gross block of code, must fix this
if( userAgent[ userAgent.length - 1 ].split( "/" )[ 0 ] === "Firefox" ) {
teDiv.style.width = ( pixelsPerSecond * ( endTime - currentSlideOptions.start ) ) / ( ( container.offsetWidth ) / 100 ) + "%";
} else {
teDiv.style.width = ( pixelsPerSecond * ( endTime - currentSlideOptions.start ) ) / ( ( container.offsetWidth - ( count ) ) / 100 ) + "%";
}
Leaving count
as 0
makes the else
branch equivalent to the Firefox branch, so I'm surprised that that seemed to worked in Chrome.
@dseif, do you remember why this was non-Firefox browsers needed special treatment?
This has a slightly difference appearance, but it's simpler and works in both Chrome and Firefox.
This looks great, so much better then what we had :)
It doesn't seem to be working on the svg examples at the moment ( are they working at all? ).
Also in the future can you create a new branch for each issue that you are working on? It makes it easier to isolate issues and review them without any other changes on master.
Also gonna need a pull request :)
Also when pressing the back arrow key it only updates the ticks every other click, defintely something that is going to have to be fixed before we can stage this.
Hmm... the SVG examples are working for me in both Chrome and Firefox.
Are you just opening them through file://
? A lot of files are referred to using host-relative paths and expect the slide-drive directory to be at /
. I guess we should change that.
I'm opening them on my localhost, so it's not via file://
. But yea, the pathing may be messed so we should probably fix that
(Just cherry-picking this change into a new branch.)