By setting the parent of the JS console, DOM inspector, view source and
download windows, they will be destroyed automatically when the main
browser window is closed.
Fixes#2373.
This is a "quirk" I've observed on a Intel ICH7 test machine. Apparently
we need to select the device (master or slave) before starting to work
with the bus master register.
It's very possible that other machines are requiring this step to happen
before the DMA transfer can occur correctly.
Also, when reading with DMA, we should set the transfer direction before
clearing the interrupt status.
For the sake of completeness, I added a few lines in places that I
deemed it to be reasonable to clear the interrupt status there.
Although unlikely to happen, a user can have an IDE controller that
doesn't support bus master capability. If that's the case, we need to
check for this, and create an IDEChannel (not BMIDEChannel) to allow
IO operations with the controller.
If the user requests to force PIO mode, we just create IDEChannel
objects which are capable of sending PIO commands only.
However, if the user doesn't force PIO mode, we create BMIDEChannel
objects, which are sending DMA commands.
This change is somewhat simplifying the code, so each class is
supporting its type of operation - PIO or DMA. The PATADiskDevice
should not care if DMA is enabled or not.
Later on, we could write an IDEChannel class for UDMA modes,
that are available and documented on Intel specifications for their IDE
controllers.
Technically not supported by the original ATA specification, IDE
hot swapping is still in practice possible, so the only sane way
to start support it is with ref-counting the IDEChannel object so if we
remove a PATADiskDevice, it's not gone with it.
An article about IDE limits states that:
"Hard drives over 8.4 GB are supposed to report their geometry as
16383/16/63. This in effect means that the `geometry' is obsolete, and
the total disk size can no longer be computed from the geometry, but is
found in the LBA capacity field returned by the IDENTIFY command.
Hard drives over 137.4 GB are supposed to report an LBA capacity of
0xfffffff = 268435455 sectors (137438952960 bytes). Now the actual disk
size is found in the new 48-capacity field."
(https://tldp.org/HOWTO/Large-Disk-HOWTO-4.html) which is the main
reason to not support CHS as harddrives with less than 8.4 GB capacity
are completely obsolete.
Another good reason is that virtually any harddrive in the last 20 years
or so, supports LBA mode. Therefore, it's probably OK to just ignore CHS
as it's unlikely to encounter a harddrive that doesn't support LBA.
This is somewhat simplifying the IDE initialization and access code.
Also, we should use the ATAIdentifyBlock structure if possible,
so now we do it instead of using macros to calculate offsets.
With the usage of the ATAIdentifyBlock structure, we now use the
48-bit LBA max count if the drive indicates it supports 48-bit LBA mode.
We now also check we have enough space in the incoming buffer for the
various signatures and optional (length specified) fields. This helps
prevents a possible heap overflow read.
This way it's easier to find the right window when many are open at the
same time, as all buttons share a limited amount of horizontal space and
titles get truncated quickly.
Because it's what it really is. A frame is composed of 1 or more samples, in
the case of SerenityOS 2 (stereo). This will make it less confusing for
future mantainability.
Instead of crashing on a missing input file, looping forever on an
invalid gzip compressed file, and crashing on permissions issues in
the output file, handle all issues gracefully by logging and returning.
Just a sanity check, this must never happen. Manual invocations of
call() e.g. in LibWeb bindings must pass js_undefined() if no specific
this value is desired, which OrdinaryCallBindThis will then use as-is or
turn into the global this value in non-strict mode.
Section 10.6.4 rule 5 of the CSS height property spec outlines a method
to compute the height of an absolutely positioned block when the 'top'
and 'bottom' CSS properties are specified.
The case for computing auto-height of block elements which have block-
level children was erroneously skipping some children:
1. If the block element itself is absolute or floating, all children
were skipped due to a likely typo ("box" vs. "child_box" inside the
for-each loop).
2. Floating children should only be skipped if the block element's
'overflow' property computes to 'visible', per section 10.6.3 of the
CSS height property spec. If the property computes to another value,
section 10.6.7 only indicates that absolutely positioned children
should be skipped.
