- The issue was caused by the check for the `bScrollOversize` option
which looks for the container being the same width as its inner
content area. Obviously that happens to be true if there is no
scrollbar. Adding a check for the clientWidth not being 100 as well
resolves this.
- I've also combined the scrollbar width detection with the other
browser detect functions. The two functions were performing very
similar operations and so easily combined
- The browser detect DOM creation will only run once, rather than for
every table initialisation, optimising multi-table loading
- Fixes DataTables/DataTables #633 - Thanks to @nddery and @epitaphmike
for the input
- If d or objectRead were truthful then the row's data object would be
replaced with an empty object. This was one shortcut in code too many!
- Relates to thread 29530 with thanks to idleog.
- This appears to be caused by setting the prototype chain as an object
directly. For example:
var test = function () {};
test.prototype = {};
$.isPlainObject( new test() );
will return `true` with jQuery 2.1.4 (and `false` for 1.11.3).
If an item is added to the prototype object then it will return
`false`, although for some reason that wasn't the case with
DataTables' API prototype.
More investigation required, but for full compatiblity with exisiting
jQuery releases, the correct thing to do here is to build on the
exisiting prototype, which we can do with `$.extend`.
- This is an interesting one, and I suspect a bit of an edge case in the
browsers - what is happening is that the window is going from having a
scrollbar to not having a scrollbar when the scrolling viewport is
collapsed. This causes the browser to show the scrollbars in the
viewport for an instant, even although they aren't actually required.
If the height of the viewport is 53px and you up it to 80 so there are
no scrollbars and reduce it back to 53 the scrollbars are gone! The
browser must be stopping a race condition once the scrollbars are
shown.
- The fix is to use `max-height` for the scrolling container if the
scroll collapse is set and `height` otherwise. The browser native
methods makes the code _much_ easier to work with, more performant and
easier to understand.
column width for these tables. However, that was in error - it is in
fact required still as the smart width calculations cause the browser to
crash (APPCRASH). There is no indication as to why this is, not is it as
simple as just disabling one or two pieces of code to stop the crash.
This leads me to suspect that it is the number of operations being
performed - particularly to do with the cloning of the elements. If this
is the case, then its just never going to work. Also IE6/7 are such a
small market now (thank goodness) this is just a feature that won't be
available in those browsers.
If anyone is interested in working on fixing it, or paying me to do so,
I'm happy to hear from you :-)
Fix: The auto width calculation table, when scrolling is enabled, being inserted into the scrolling container could cause the viewport to scroll, even when the main table doesn't actually need scrolling. This causes the column width calculations to be incorrect by the scrollbar's width. The fix is to have the calculation table `position:absolute` in the scrolling container and height:1px so it has no effect on the vewport's scrolling.
- These two fixes address DataTables/DataTables #612. Kudos to @Delgan
for reporting these issues and supplying test cases - thanks!
- Bootstrap is proving to be a far more popular theme for DataTables -
this example comes from back in the day when jQuery UI theming was
first added, so it is no longer required.
Fix: Table could overscroll if `dt-init data` is used to populate the table
This is a fairly significant change to how DataTables operates for the
scrolling width calculations and primarily is due to a simplification
with the use of `clientWidth` to get the scrolling container width.
Rather than getting the offsetWidth and then removing the scrollbar
width if required the `clientWidth` will give us the value directly.
With the scrollbar width already accounted for the scrolling draw code
can be updated to not need to account for it itself.
Finally, when using the `data` property to add data to the table we need
to recalculate the column widths after the first draw, just like with
Ajax loaded data, otherwise the data added won't be taken into account
and we can get an error in the scrolling.
Dev: Syntax highlighter - show the type label above the code so it doesn't over lap the code
Dev: Syntax highlighter - don't show the `:after` option in highlighted code
- Have used :after for the information about what type of link it is -
this stops it from being included in a copy / paste which was annoying
- The postfix is a bit more informative than a letter about what
software it relates to
- With the move to the 1.10 API for all of the extensions, showing the
extension letter was redundent anyway
- Adding -button link type
- Improved the colours
when body's position is changed (left: 375px) _fnBrowserDetect incorrecly calculates offsets. thus header is a bit misaligned. commit changes test object's position to fixed. in this case it's position will
be relative to the viewport not to the body.
When the table was being destroyed and the remove parameter was passed
in as `true` to remove the table from the DOM there was potential for
bound events to not be unbound from the table elements. This was caused
by the use of the `detach` jQuery method which will not remove events.
Furthermore, rows would not be added to the table before this method (or
`remove()`) was called. As such we need to reorder the code slightly -
attach the rows back into the DOM and then remove them (or detach if the
table is left in the DOM) - otherwise rows which were hidden by paging
would not have their events unbound.
Many thanks for KnowledgeNet ( http://kn-it.com/ ) for their support in
finding and allowing this bug to be addressed!