The full URL (hostname and path) is only inside the HTTP protocol and is thus encrypted by the TLS layer. Also, any HTTP headers and payload of request and response are end-to-end encrypted. But, the hostname part of the URL is usually in the CONNECT request when using a non-transparent HTTP proxy, unless the client itself makes the DNS lookup. With a SOCKS proxy the situation is similar, i.e. the client provides the target IP (SOCKS4) or might provide the hostname (SOCKS5). Additionally the hostname is usually included in the TLS handshake too in clear (SNI), no matter if using a proxy or not.
This means it is known to the provider of the proxy (maybe the ISP) which host your are accessing but not which page on this host. Also any hop after the proxy knows at least the target IP because this is needed for routing. And if SNI is used (i.e. in most cases) any hop can also find out the targets host name.
In short: the goal of TLS is not to keep privacy or to allow anonymous connections. The goal is to protect the data transferred between client and server against sniffing and modification.
And who does the DNS lookup?
With a SOCKS4 proxy it must be done by the client (browser). With a SOCKS5 proxy or a HTTP proxy it can and will usually be done by the proxy since these protocols can transport the hostname instead of the IP address.
Edit: I was not aware that recent versions of Firefox and Chrome actually support connecting to a HTTP proxy with HTTPS. In this case only the connection to the proxy is visible to any hop before the proxy and thus the URL including the hostname and IP address is fully protected on the path to the proxy. On and after the proxy this additionally TLS protection is removed and thus the hostname and target IP address are visible again as described above. I would assume that the browser sends the hostname and not the IP address to the proxy (because this is done with a normal HTTP proxy too), so the DNS lookup will only be done at the proxy.