Is this approach able to protect against padding oracle attacks? I know that a protection against the padding oracle attack is to encrypt-then-mac. This is to avoid trying to decrypt a modified ciphertext, and leak information about padding errors.

Suppose that we have a content which is signed, and then encrypted. For decryption and signature control, this content is processed in the following manner:


decrypt the content without telling if the padding is correct on not. 
check the signature on the decrypted content and return an error if it is incorrect, which should be the case if the ciphertext was modified.


Is this treatment correct when wanting to avoid PO attacks (or any other chosen ciphertext attacks)?

To be more precise, the scenario would be:


the content is signed with an asymetric key (say a RSA-PSS signature), 
it's then encrypted with a symetric algo (say AES-256-CBC), with a random 
key and a random IV,
the symetric key is encrypted with another asymetric key (say a RSA-OAEP encryption),
the ciphertext, the encrypted symetric key and the IV are then transmited to a receiver process.
the receiver process decrypts the symetric key without telling if there is a padding error (OAEP padding)
it then decrypts the ciphertext with the (possibly badly decrypted) symmetric key without telling if there is a padding error (AES-256-CBC padding)
it then checks the signature on the (possibly badly decrypted, but good sized) content and returns an error if it is incorrect, rejecting the received content.
You have to differentiate between it being theoretically OK and practically. Without fully checking, I can say that such an approach may be possible to fully prove. However, practically, it is almost impossible to implement it. Specifically, you have to be able to make it impossible to differentiate between an error due to the symmetric decryption or the signature. However, this is really hard to do (actually, pretty much impossible). The reason is that you need to make it time-independent. But, if you have a padding error, you don't even know how long the message is to verify. The Lucky13 attack on TLS worked exactly because code that was written to be time-independent turned out to not truly be so in certain cases. So, I would never do such a thing.

A huge number of SSL/TLS weaknesses are due to doing MAC-then-encrypt, so don't do this. GCM is so fast today on Intel processors that there's no reason not to use (just make sure you always have a different nonce).