Controlul browserului din aplicație

Ce face

control-in-app-browser este capabilitatea prin care sistemul poate folosi browserul integrat al runtime-ului ca suprafață vizuală și interactivă: deschide pagini, navighează, inspectează ce este vizibil, identifică elemente interactive, apasă butoane, completează câmpuri, face capturi de ecran și testează aplicații web locale.

Pe scurt: se folosește când trebuie văzută sau atinsă interfața unei pagini, nu doar citit conținutul unui link.

Browserul poate avea sesiuni deja autentificate, dar asta nu îl transformă în unealta implicită pentru orice URL. Pentru operații semantice pe resurse — citire, rezumare, căutare, verificare, editare sau revizuire — sistemul trebuie să caute întâi un conector dedicat, un API, un CLI sau altă unealtă mai potrivită, dacă există. Browserul rămâne alegerea corectă pentru UI, stare vizibilă și interacțiune.

Vezi și All guides pentru restul capabilităților.

Când îmi folosește

Îți folosește când cererea este explicit despre browser, pagină, navigare sau interfață:

„deschide pagina asta în browser” „intră în browserul din aplicație” „navighează la URL-ul ăsta” „verifică ce se vede pe pagină” „apasă pe butonul X” „completează formularul” „fă screenshot” „testează interfața locală”

Diferența importantă: un URL singur nu este automat o instrucțiune de browser. Dacă spui „rezumă documentul din link”, linkul este context. Sistemul trebuie să aleagă întâi suprafața potrivită pentru document, nu să pornească browserul din reflex. Dacă spui „deschide linkul și spune-mi ce se vede”, browserul este intenția explicită.

Cum îl invoc / declanșez

Nu există o comandă publică unică garantată pentru toate instalările. Capabilitatea se declanșează natural prin cereri despre browser sau UI.

Formulări bune:

„Deschide în in-app browser pagina …” „Navighează la … și spune-mi ce butoane sunt vizibile” „Apasă pe Login” „Scrie textul ăsta în câmpul de căutare” „Fă screenshot la pagina curentă” „Testează aplicația locală și vezi dacă formularul răspunde”

Dacă numești explicit browserul din aplicație, alegerea rămâne valabilă pentru task. Sistemul nu trebuie să îl înlocuiască automat cu alt browser sau cu altă unealtă. Dacă browserul cerut nu este disponibil în sesiune, răspunsul corect este să spună că nu este disponibil, nu să pretindă că l-a folosit.

Dacă nu numești un browser, dar ceri o acțiune vizuală sau interactivă asupra unei pagini, runtime-ul poate alege suprafața de browser disponibilă cea mai potrivită.

Exemplu practic

Cerere:

„Deschide în in-app browser pagina de test și verifică dacă butonul Save este vizibil.”

Ce ar trebui să facă sistemul:

1. Recunoaște intenția explicită de browser.
2. Verifică dacă browserul din aplicație este disponibil în sesiune.
3. Navighează la pagina cerută.
4. Inspectează starea vizibilă și elementele interactive.
5. Raportează dacă butonul Save există, dacă pare activ și, la nevoie, atașează sau indică o captură de ecran.

Altă cerere:

„Rezumat la documentul din linkul ăsta.”

Aici browserul nu este prima alegere. Sistemul trebuie să caute întâi o unealtă semantică potrivită pentru acel tip de resursă. Browserul intră în scenă doar dacă nu există o cale mai bună sau dacă îi ceri explicit să inspecteze pagina vizual.

Output / unde aterizează

Outputul este răspunsul conversațional al sistemului: ce pagină a deschis, ce a văzut, ce elemente interactive există, ce a apăsat, ce a completat și ce nu a putut face.

Pentru capturi de ecran, rezultatul poate include imaginea sau o referință livrabilă prin runtime, în funcție de instalare.

Pentru testare locală, outputul util este verdictul verificabil: pagina se încarcă sau nu, controalele răspund sau nu, unde apare eroarea și ce stare vizibilă confirmă rezultatul. Dacă pagina nu poate fi accesată sau acțiunea nu poate fi executată, sistemul trebuie să spună asta direct. Nu se inventează rezultate.

Limite / gotchas

Browserul nu este un înlocuitor pentru API-uri, conectori sau CLI-uri dedicate. Dacă există o unealtă mai potrivită pentru operația cerută, aceea este preferată, cu excepția cazului în care ai cerut explicit browserul.

Nu se inspectează cookies, parole, profiluri, local storage, session storage sau alte surse de secrete. O sesiune autentificată poate fi folosită ca suprafață de lucru, nu ca depozit de credențiale.

Dacă autentificarea blochează navigarea în browserul ales explicit, sistemul trebuie să îți ceară să te autentifici în acel browser și să revii când este gata. Nu trebuie să ocolească blocajul cu web search, alt site sau altă sursă. Nu schimbă browserul decât dacă ceri sau aprobi asta.

Taburile pot expira, se pot închide sau pot deveni invalide. Asta nu înseamnă că browserul este stricat; înseamnă că trebuie obținut sau deschis un tab nou.