2015-05-25 7 views
156

Google Chrome non aggiorna gli elementi di accessibilità (AutomationElement) quando un utente scorre verso il basso nel browser.Problema della cache dell'albero accessibile di Google Chrome con UI Automation

di riprodurlo:

  1. Abilita renderer accessibilità: "chrome --force-render-accessibility" o impostando Global Accessibility presso "chrome://accessibility".
  2. Vai http://en.wikipedia.org/wiki/Google
  3. aperto inspect.exe in modalità Automation UI (da Windows Kit), cercare "Link ad articoli correlati" Element.
  4. tornare a Chrome, scorrere fino a quando "Link ad articoli correlati" in basso è visibile
  5. "Link ad articoli correlati" elemento è contrassegnato fuori dallo schermo

ho trovato alcune soluzioni manuali che può costringere Chrome per aggiornarlo:

  1. Zoom al 90% quindi impostare di nuovo al 100% (modo molto molto brutta)
  2. interruttore ACCESSIBIL lità off poi accendere in chrome://accessibility/

Quello che sto cercando è la capacità di fare una di queste operazioni programatically, o qualsiasi operazione che può rendere Chrome aggiornare il suo albero di cache.


Quello che ho provato:

  • finestra Ridimensiona con PInvoke/MoveWindow
  • Ridisegna Finestra con PInvoke/Redrawwindow
  • Costruire un'estensione Chrome e la forza zoom al 100% a richiesta: chrome.tabs.setZoom(null, 0); (lavora ma lampeggia e rallenta la finestra)

Nessuno di questi funziona correttamente.

EDIT: Testato con Google Chrome 40.XX, 41.XX, 42.XX, 43.XX, 44.XX, 45.XX, 46.XX, 47.XX.Dev, 48.XX. Dev su Windows 7.

+13

Dovresti segnalarlo al bug di accessibilità di chromium su Windows: https://code.google.com/p/chromium/issues/list?q=Cr%3DUI-Accessibility+os%3Dwindows –

+5

Puoi condividere alcune informazioni su cosa stai cercando di fare una volta risolto il problema? forse c'è una soluzione ... – DoronG

+0

@ Ksv3n per favore pubblica il link al bug che hai postato –

risposta

-1

L'architettura multiprocesso di Chrome è diversa da quella di qualsiasi altro browser. Per motivi di sicurezza, l'interfaccia utente principale del browser si trova in un unico processo e le pagine Web vengono eseguite in processi di rendering separati (in genere uno per scheda). I processi di Renderer sono gli unici con una rappresentazione del DOM della pagina web e quindi tutte le informazioni di accessibilità, ma i processi di rendering non sono specificatamente autorizzati a interagire con il sistema operativo (invio o ricezione di eventi o messaggi) - in particolare, il renderer i processi non possono inviare o ricevere eventi di accessibilità.

1

Lo scorrimento in pagine semplici è ottimizzato per non richiedere calcoli dal renderer. Sono necessari solo il compositore e la GPU per scorrere, quindi l'albero di rendering che viene aggiornato solo dal renderer è sempre lo stesso.

Richiedere al renderer di attraversare il DOM e aggiornare l'albero di accessibilità durante una pergamena è in contrasto con lo sforzo di diversi anni di avere uno scorrimento fluido, specialmente per i dispositivi touch, quindi non penso che otterrete la trazione su un bug risolvere.

La tua idea di un'estensione credo sia il migliore (anche se brutto) compromesso. Ma piuttosto che cambiare lo zoom, fare una piccola mutazione della pagina (o DOM) potrebbe essere una soluzione migliore. Prova ad esempio aggiungendo un elemento invisibile (o quasi) con un basso ordine z. Dovrai inoltre valutare il controllo della mutazione in modo che si verifichi solo 1 volta al secondo o anche meno spesso.

+0

Rompere l'accessibilità quando è esplicitamente richiesto nella configurazione o nei parametri, in nome dello smother lo scorrimento sembra scadente. – manuell

+1

@manuell è per questo che esistono le estensioni. Quando le tue priorità sono in contrasto con le priorità del browser, puoi prendere il sopravvento. Il cliente che installa il segnale di estensione è d'accordo con te e non con il team di Chrome. – AlienRancher