Het opsporen van scroll-gerelateerde problemen is nu nog eenvoudiger met de nieuwe scroll-badge van DevTools! In dit bericht wordt uitgelegd wat schuifbare elementen zijn, waarom ze moeilijk te vinden kunnen zijn en hoe deze nieuwe functie je helpt ze snel te vinden. We nemen je ook mee achter de schermen om te zien hoe we de scrollbadge hebben ontwikkeld.
Wat is een scrollbaar element?
Als u door de inhoud van een element kunt scrollen, is het een scrollbaar element (of scrollcontainer ). Het maakt niet uit of er schuifbalken zijn of niet.
Waarom is het moeilijk om het schuifbare element te vinden?
Het opsporen van scrollproblemen is lastig. Zonder een hulpmiddel om het schuifbare element duidelijk weer te geven, kun je gemakkelijk verdwalen, vooral op complexe pagina's als er geen schuifbalken zijn.
Het handmatig vinden van het element dat aan het scrollen is, kan een moeizaam proces van vallen en opstaan zijn:
- U kiest een element en wijzigt de stijlen ervan.
- Is de schuifbalk verdwenen? Als dit niet het geval is, herhaalt u het proces.
Introductie van de scroll-badge
In Chrome 130 kun je de nieuwe schuifbadge in het Elementenpaneel gebruiken om de schuifbare elementen te vinden!
Probeer bijvoorbeeld te achterhalen welk element ervoor zorgt dat de schuifbalken in het volgende voorbeeld verschijnen met behulp van de nieuwe schuifbadge.
Technische implementatie van de nieuwe scrollbadge
Achter de schermen is de implementatie opgesplitst in twee delen:
- Scrollbare elementen identificeren . Gebruik de signalen
Blink's(de weergave-engine van Chrome) om elementen te identificeren die scrollbaar zijn of scrollbaar zijn geworden als gevolg van een verandering op de pagina. - De scroll-badge weergeven . Na ontvangst van de signalen nemen we een nieuwe badge op (vergelijkbaar met de bestaande rasterbadges ) naast de schuifbare elementen in het paneel Elementen .
Scrollbare elementen identificeren
Om schuifbare elementen te identificeren, hebben we de IsUserScrollable -methode in Blink gebruikt. Deze methode bepaalt of een knooppunt scrollbaar is door te controleren of het overloopt langs de X- of Y-as, wat aangeeft dat de inhoud de containerafmetingen overschrijdt en kan worden gescrolld. We noemen deze methode elke keer dat een nieuw element in DevTools wordt geladen om schuifbare containers te identificeren.
Voor het dynamisch bijwerken van de schuifbaarheidsstatus van elementen die al zijn geladen, moesten we diep in de codebasis van de Blink-renderingengine duiken om bij te houden waar het schuifbare gebied voor een knooppunt wordt toegevoegd of verwijderd.
De kernlogica die de overflow afhandelt, wordt beheerd door de component PaintLayerScrollableArea . Concreet is de UpdateScrollableAreaSet -methode verantwoordelijk voor het detecteren wanneer overflow heeft plaatsgevonden of is opgelost.
Deze informatie wordt doorgegeven aan de DevTools-backend door de referentie te verzenden van het knooppunt dat zijn ScrollableArea heeft gewijzigd.
De backend controleert vervolgens het knooppunt opnieuw met behulp van de IsUserScrollable -methode om de nieuwe status te verkrijgen. Nadat de scrollbaarheid is geverifieerd, wordt er een signaal naar de frontend gestuurd met behulp van het Chrome DevTools Protocol , zodat de gebruikersinterface de veranderingen in de scrollbare inhoud accuraat weergeeft.
De scroll-badge weergeven
Om de nieuwe badge aan de frontend van DevTools toe te voegen, hebben we een handlermethode gemaakt in de ElementsTreeOutline die de nodeId ontving van het element dat de schuifbaarheidsstatus veranderde door een gebeurtenis. In die handler halen we het ElementsTreeElement -object op met behulp van de nodeId en instrueren we het om de scroll-badge bij te werken.
Bij het bijwerken van de scrollbadge wordt gecontroleerd of het element scrollbaar is en of het al een scrollbadge heeft. Op basis van deze voorwaarden worden de volgende acties ondernomen:
- Als het element scrollbaar is en nog geen scrollbadge heeft, wordt er een toegevoegd.
- Als het element niet scrollbaar is maar wel een scrollbadge heeft, wordt de bestaande badge verwijderd.
De speciale logica voor het verwerken van scrollbare documenten op het hoogste niveau
Wanneer het document op het hoogste niveau schuifbaar is, is er sprake van een speciaal geval omdat we het #document element voor het hoofddocument niet weergeven, alleen voor iframes. Als gevolg hiervan kunnen we de badge niet rechtstreeks op #document -elementen weergeven
We hebben besloten om in plaats daarvan de scroll-badge op het </html> -element weer te geven, inclusief die in Quirks mode waarbij document.scrollingElement() de <body> of null retourneert. Deze beslissing voorkomt verwarring tussen schuifbare documenten en schuifbare hoofdtekstelementen, vooral op pagina's waar de hoofdtekst onafhankelijk kan worden gescrolld.
We hebben ontdekt dat dit de duidelijkste manier is om ontwikkelaars te laten zien door welke elementen kan worden gescrolld.
Wijzigingen in het Chrome DevTools Protocol (CDP).
Om de nieuwe scroll-badge te integreren waren wijzigingen in Chrome DevTools Protocol (CDP) vereist. CDP dient als communicatieprotocol tussen DevTools en Chrome.
We moesten het protocol wijzigen om de twee gevallen af te dekken:
- Is dit knooppunt scrollbaar wanneer het in DevTools wordt geladen?
- Heeft dit knooppunt de schuifbare status bijgewerkt?
Is dit knooppunt scrollbaar wanneer het in DevTools wordt geladen?
We hebben een nieuwe eigenschap met de naam isScrollable toegevoegd aan het gegevenstype DOM.Node dat elke keer wordt verzonden wanneer een nieuw knooppunt wordt geladen in de DevTools-frontend.
We hebben besloten deze eigenschap alleen in te vullen als deze waar is, om te voorkomen dat onnodige gegevens worden geladen. Wanneer de eigenschap niet wordt verzonden, gaan we er daarom van uit dat het element niet kan worden gescrolld.
Heeft dit knooppunt de schuifbare status bijgewerkt?
Om te detecteren of een knooppunt zijn schuifbare status heeft bijgewerkt, hebben we een nieuwe gebeurtenis scrollableFlagUpdated geïntroduceerd in CDP, die wordt geactiveerd wanneer een element een schuifbaar gebied wint of verliest. Het evenement heeft de volgende structuur:
# Fired when a node's scrollability state changes.
experimental event scrollableFlagUpdated
parameters
# The id of the node.
DOM.NodeId nodeId
# If the node is scrollable.
boolean isScrollable
Pro tip: Bekijk de nieuwe CDP-wijzigingen in uw browser
Als u nieuwsgierig bent naar hoe Chrome communiceert met DevTools, kunt u dit op een eenvoudige manier verkennen.
In het paneel Protocolmonitor kunt u realtime gebeurtenissen bekijken die zijn uitgewisseld tussen Chrome en DevTools, inclusief de nieuw toegevoegde gebeurtenis voor de Scroll-badge. Wanneer u bijvoorbeeld de stijl van een element wijzigt, wat van invloed is op de scrollbaarheid ervan, kunt u onmiddellijk de gerelateerde CDP-gebeurtenissen zien zodra ze plaatsvinden.
Zie Protocol monitor: View and send CDP requests voor een meer gedetailleerde handleiding.
Beyond Scrolling: Maak kennis met de overflow-badge
Sterker nog, we werken aan een nieuwe overloopbadge om de oorzaak van dat scrollen te achterhalen. Deze badge verschijnt naast elementen die overlopen in hun container, zodat u lay-outproblemen snel kunt diagnosticeren.
Hier ziet u hoe het zal werken:
- Interactieve foutopsporing . Klik op de schuifbadge om een DevTools Protocol-opdracht te activeren die overlopende onderliggende elementen identificeert.
- Overloop visualiseren . We brengen de elementgrenzen binnen de schuifbare container in kaart om eventuele overloop te detecteren.
- De dader onder de aandacht brengen . De overloopbadge markeert deze overlopende elementen en als u erop klikt, worden ze direct in de DOM gemarkeerd.
Dit geeft ontwikkelaars een krachtig nieuw hulpmiddel om lay-outproblemen veroorzaakt door overvolle inhoud te begrijpen en op te lossen. Wij zijn ervan overtuigd dat dit diepere analyseniveau uw debugging-workflow aanzienlijk zal stroomlijnen.