'Oude XP-bug is nog steeds aanwezig in laatste updates voor Windows 10'

De recente November 2019 Update voor Windows 10 bevat nog steeds de bug die contextuele uitklapmenu’s soms achter de taakbalk laat belanden. Het probleem werd voor het eerst gerapporteerd na de April 2018 Update, maar blijkt mogelijk al te dateren van het XP-tijdperk.

De desbetreffende bug treedt op wanneer de gebruiker het contextuele uitklapmenu van een applicatie in het systeemvak wil openen. Een deel van het uitklapmenu belandt daarbij soms achter de taakbalk, waardoor met name de onderste opties niet geselecteerd kunnen worden. Het probleem doet zich onregelmatig voor en treft verschillende apps. Bij sommige programma’s lijkt de bug wel vaker op te treden. Als voorbeeld noemt Softpedia de instant messenger Pidgin.

De Windows 10 November 2019 Update versie 1909 brengt hier volgens Softpedia geen verandering in. En dat terwijl de bug al gerapporteerd werd kort na het verschijnen van de April 2018 Update 1803. Softpedia sluit niet uit dat Microsoft het probleem ergens tussen april 2018 en november 2019 heeft opgelost, maar dat de bug op een bepaald moment is teruggekeerd.

Meerdere gebruikers laten via de fora van Softpedia inmiddels weten dat de desbetreffende bug eigenlijk al dateert van het Windows XP-tijdperk. Een gebruiker met de naam Avant schrijft dat het probleem veroorzaakt wordt door het feit dat de taakbalk zich te allen tijde op de voorgrond wil bevinden, ‘en dit al minstens sinds de introductie van Windows XP’.

De foutieve weergave van het uitklapmenu kan niet actief worden voorkomen. Wanneer de bug optreedt, kan het probleem worden omzeild door naast het uitklapmenu te klikken, en vervolgens met de rechter muisknop opnieuw op de app in het systeemvak te klikken.

Schermafbeelding: Softpedia

Reacties (117)

[Zebby]

Tja, ze zullen wel honderden zo niet duizenden bugs hebben, dit lijkt me een gevalletje "low" op alles. Prioriteiten... Wel leuk dat het na zo veel volledige rebuilds er nog steeds is?

[Archcry]

Ik vind dit ook niet echt een nieuwswaardige bug. Het is niet alsof het om een beveiligingsprobleem gaat ofzo. Er zitten ongetwijfeld nog wel meer bugs in Windows die uit het jaar 0 stammen, gaan we daar dan ook een artikel over schrijven? Ik vind het vooral niet echt spannend omdat het om iets gaat wat niet eens blokkerend is voor het gebruik van het besturingssysteem.

Edit: Typefoutje

[Reactie gewijzigd door Archcry op 23 juli 2024 07:38]

[Verwijderd]

mijn favoriete jaar 0 bug: folders die hun view settings niet onthouden

[Ayporos]

ugh ja daar stoor ik me ook, nog steeds, mateloos aan.

[_Pussycat_]

En dat apply view to all folder niets doet. Ik wil gewoon altijd een lijst met details. Inderdaad frustrerend dat Windows altijd wil helpen i.p.v. te luisteren

[mae-t.net]

Juist bugs die er lang inzitten of opnieuw terugkeren zijn interessant omdat het inzicht geeft in de manier van ontwikkelen of gewoon omdat het grappig is. Laten we blij zijn dat het geen ernstige bugs zijn die er al heel lang inzitten!

[laptopleon]

Eh… niet spannend omdat het besturingssysteem niet eens blokkeert? Het besturingssysteem is een middel, geen doel. Het doel is het effectief draaien van de applicatie en dat kan nu niet want de gezichte functie wordt geblokkeerd door het OS.

Dit is in bepaalde opzichten erger dan een beveiligingsprobleem want dit treedt altijd op. Anderzijds is er vaak redelijk eenvoudig omheen te werken, als ik bet goed begrijp.

Overigens redelijk hilarische bug dit. Gewoon raar ook dat de taakbalk altijd bovenop miet blijven.

[SuperDre]

Je kunt ook stellen dat het een probleem van de applicatie zelf is, immers deze popt het menu niet op BOVEN/ONDER/NAAST (afhankelijk van waar je de taakbalk hebt) de taakbalk maar op de plek waar de taakbalk zit.
Moet je eerlijk zeggen dat ik er met mijn eigen applicatie nog nooit last van gehad, en ik pop em ook gewoon op waar de muislokatie is. Maargoed, dit soort dingen kunnen altijd gebeuren, heb ergere zaken meegemaakt zoals het oppoppen van een file save dialog die dan ineens verdwijnt achter andere applicaties omdat ik even iets anders aanklik, en dan alleen terug te halen is door eerst alle andere applicaties te minimizen..

[latka]

Ik vind het wel belachelijk dat het positioneren van een pop-up door de applicatie moet gebeuren. Voor de consistentie zou je juist verwachten dat dit door de OS UI toolkit moet gebeuren en dat je daar niets aan kunt veranderen (maar goed, ben dan ook geen win32 programmeur).

[SuperDre]

Je hebt daar als developer keuze in, je moet het menu ergens op laten poppen, en normaal gesproken doe je dat bij dit soort menu's bij de positie van de muis. Maar bij Win32 heb je helemaal de controle over waar je em wilt laten oppoppen En dat is maar goed ook, hou graag zelf wat controle (maargoed, genoeg Win32 zaken die bij windows GUI's een ramp zijn (zeker zodra mensen hun fonts groter ingesteld hebben, grootste ramp vind ik dus dat de WINAPI je soms andere informatie teruggeeft dan die je verwacht (zeker met window related API calls en specifiek bepaalde manifests moet meeleveren).

[Aanwezig]

Juist. Applicatie, vermoedelijk GTK port of QT van het voorbeeld Pidgin doet een verkeerde API call. Je ziet het ook wel eens in games als ze aan het laden zijn dat de taakbalk er over heen valt. Anderzijds kan je zeggen dat dit nimmer mogelijk moet zijn, want wat is nou een use case waar dkt gewenst zou zijn? Bonzai buddy dat naar boven loopt?

[Archcry]

Ik vind het vooral niet echt spannend omdat het om iets gaat wat niet eens blokkerend is voor het gebruik van het besturingssysteem.

Ik heb het niet over het blokkeren van het OS gehad. Ik zeg alleen dat de bug niet blokkerend is voor het gebruik van het OS. Als in, wanneer het probleem zich voordoet denk je eventjes "wtf" en ga je daarna weer door met waar je mee bezig was. Vandaar niet zo spannend voor mij persoonlijk dus. Het kan zijn dat jij dat anders ziet.

[Reactie gewijzigd door Archcry op 23 juli 2024 07:38]

[parzival110]

Niet echt spannend, waarom is het dan nog niet opgelost als het toch een makkelijk probleem is?

[Archcry]

Waar zie je mij zeggen dat het een makkelijk probleem is om op te lossen? Ik zeg alleen dat het vanuit een gebruikersperspectief niet zo spannend voor mij is

[akooijman]

Microsoft maakte in 2018 tien miljard dollar winst, keerde zes miljard dollar uit aan aandeelhouders, maar laat een tien jaar oude bug gewoon voor wat hij is.
Dat maakt duidelijk waar de prioriteiten liggen: in elk geval niet bij de gebruikservaring voor de eindgebruiker.

[EmJeeYT]

Ik ben het met je eens dat dit niet op het prioriteitenlijstje zal staan van Microsoft.
Het is natuurlijk wel de vraag of na al die rebuilds het probleem er 'nog steeds is' of mogelijk weer terug is gekomen?

[Ask!]

Is toch vrij makkelijk op te vangen in een unit test / integratie test denk ik?
Dan keert het ook niet terug als het goed is (als je tenminste de oorzaak gevonden hebt natuurlijk)

[Reactie gewijzigd door Ask! op 23 juli 2024 07:38]

[gast128]

Het is een UI aspect. Ik weet niet of dat zo makkelijk in een unit test te vatten valt.

[Pep7777]

Waarschijnlijk niet zonder flinke refactoring om het unit testable te maken.
Lees interfaces en mocks toevoegen die z-order van pixels/windows delen kunnen valideren...
Niet onmogelijk maar vaak vind men refactoren van legacy code ook weer te risicovol omdat er geen unit test zijn

[Verwijderd]

Een tweede poging met klikken is een workaround en het probleem doet zich onregelmatig voor. Veel succes met je unit test, maar dit lijkt op threading issues. De kans dat het probleem in taakbalk code zit is daarmee ook klein. Dit zit dieper.

[supersnathan94]

Maar als het goed is zou dit allemaal vrij nieuw moeten zijn. Dus legacy verwacht ik niet echt. Dit is gewoon basis functionaliteit van het OS. Had prima getest kunnen worden.

[Kalief]

Dan moet het wel reproduceerbaar zijn.

[DJMaze]

Ik heb de oorzaak ooit gevonden en het is niet alleen het contextmenu (ook vensters kunnen er "onder" verdwijnen).
Heb er eigenlijk nooit bij stil gestaan om het te rapporteren of op te zoeken.
Zie het als velletjes papier op elkaar (css z-index).
Het menu is een klein breed velletje.
Vervolgens komen er contraints op de client area zodat de "bottom" boven het menu is (scherm van 1080 is dan bijvoorbeeld 1020).
Nou is het menu de contraints kwijt en teken je het contextmenu met bottom 1080 en niet met 1020.
En dan is ook nog eens de "z-index" van je contextmenu lager dan die van het windows menu.
Dan "schuift" je contextmenu velletje papier dus onder die van het windows menu.

Forceer een top index op het contextmenu en soms werkt dat (want meestal is het alleen een Z waarde probleem).

Het is vooral irritant als je "modal" venster achter het normale venster beland. Zit je hele applicatie "vast".

[Reactie gewijzigd door DJMaze op 23 juli 2024 07:38]

[roger128]

Het probleem hierbij is het "soms" gedeelte. Een unit test zal alleen een vooraf geschreven testscenario doorlopen. Maar blijkbaar is het dus niet zo zwart-wit wanneer het zich wel of niet voordoet. Het kan dan zijn dat een test succesvol afgerond word omdat ofwel het probleem zich dit keer niet voordeed, of omdat de gevallen waarin het kan gebeuren niet allemaal zijn afgevangen in het testscenario

[Znorkus]

Dan ben je wel een beetje een slachtoffer aan het worden van je eigen logge protocols, als je met bugs die soms optreden niet zoveel kan

[roger128]

Ieder serieus stuk software heeft last van bugs die "soms optreden". Uiteraard is het geen volledige willekeur, maar is het gewoon niet duidelijk onder welke exacte omstandigheid het gedrag wel en niet voordoet.

Tenzij je je hele systeem formeel hebt geverifieerd zit dit in ieder groot stuk software. Ik weet men het leuk vind om met z'n allen te haten op het "logge Windows", (en ik zal ook niet ontkennen dat het misschien wat meer voorkomt bij Windows), maar iedere simpele gui gaat hier last van hebben, dus een OS al helemaal

[casberrypi]

Als je de bug op een correcte manier hebt opgelost (dus niet het symptoom bestreden bijvoorbeeld) kun je exact vertellen onder welke situaties die bug optreedt. Dan kun je er gewoon een unit test voor schrijven.

Overigens hilarisch om te lezen hoe 'Tweakers' hier hun beperkte CSS kennis loslaten op een operating system.

Overigens claim ik niet dat ik kennis heb van de internals van de Microsoft Windowmanager, zelfs niet als gebruiker. Ik ben al ruim 15 jaar geen Windows gebruiker meer. Wat ik wel kan zeggen: het is geen CSS. GTK+ trouwens wél, en dat is erg cool.

[akooijman]

Uhm... dus software zonder bugs is niet serieus te nemen?

[SlasZ]

Misschien dat de media aandacht die het (onterecht) krijgt er nu wel voor zal zorgen dat Microsoft het zal oplossen. Idem met alle dingen die tegenwoordig media aandacht krijgen (onrechten, pech etc): lijkt de enige manier om iets gedaan te krijgen helaas.

[Bossie]

Een rebuild van al bestaande code dus

[Genosha]

Ik heb deze bug serieus nog nooit gezien in Windows 7 noch 10.

[Renegade666]

Ik het tegen overgestelde, 7, 8.1 en 10 hebben er last van.
Gebeurd niet vaak, maar toch wel paar x in de maand.

[parzival110]

Lage prio maar wel een makkelijke fix, z-index verhogen ... Dat ze dit jaren laten liggen is gewoon slordig programmeren en slecht project management want het kost niets om er een developer op te zetten aangezien dit een klus is van maar een paar dagen.

[Zebby]

Je hebt nooit in een corporate bedrijf gewerkt zeker, dit is zo'n beetje standaard. Heel vervelend, ook voor de developers soms, maar er is altijd wel een hoge prio waar aan gewerkt moet worden. En een klus van een paar dagen kost ze dus al snel meer dan 10k voor iets waar ze niks mee verdienen. Uren van de developer, maken van testen, eventueel UAT, project manager/scrum master/product owner die er wat van moeten vinden, deployment naar een patch, patchnotes... Zo kan een fix van een half uurtje zo een aardige stapel geld kosten.

Soms doen dit soort bedrijven een bug squash event, waar je dit soort mini dingen oppakt, vooral user interface ipv technisch of functioneel.

[akooijman]

"... waar ze niks mee verdienen..."
Ze verdienen er respect mee als ze aandacht besteden aan slordigheden.
Slordigheden laten zitten zegt iets over de mentaliteit van de ontwikkelaars.
Slordig programmeerwerk hoort niet bij de klant terecht te komen.
Kleine maar zichtbare foutjes zijn symptomen van broddelwerk.

[parzival110]

Zebby, jij bent mocro zeker? En ja, ik heb als senior software engineer gewerkt voor meerdere multinationals. Zonder de naam te noemen heb ik voor een bedrijf gewerkt dat als het niet bestond jij geen werk zou hebben omdat je geen chips zou hebben, dus geen PC. Vandaag ben ik CEO van een 3 corporate IT bedrijven en ik verdien waarschijnlijk 10x meer dan jij dus ik weet echt wel wat het kost om een dev op een klus te zetten van een paar dagen. Met jouw grote mond zou je beter even nadenken voor je iemand voor schut zet.
Dus standaard irritante bugs laten liggen? Een probleem met een lage prioriteit dat gebruikers irriteert is een probleem met een verkeerde prioriteit. En als je er als bedrijf geen tijd voor hebt, dan moet je echt hard gaan nadenken of jouw developers en project managers wel goed bezig zijn.
En dan een klus van 2 dagen 10k? Hoeveel verdien jij als developer? 5000 per dag? Vooral blijven dromen.

[Reactie gewijzigd door parzival110 op 23 juli 2024 07:38]

[delphium]

Wat me meer zorgen baart, is dat Microsoft al bij Windows 7 zei dat het systeem van de grond af opnieuw gebouwd zou zijn. Diezelfde belofte kregen we bij Windows 10. Kennelijk is de stagiair van toen blijven hangen en heeft keer op keer dezelfde fout in zijn code gestopt

[Verwijderd]

Ik kan me die beloftes niet herinneren eerlijk gezegd. Windows 7 was sowieso gebaseerd op Vista, dat een snelle fix was na gefaalde Longhorn. Als ik het mij goed herinner werd de reset gebaseerd op Windows Server 2003 kernel.

Maar een complete rewrite met Windows 7 is zover ik weet nooit sprake van geweest. MS had zijn lesje wel geleerd na Longhorn.

[Blokker_1999]

Zelfs dat is niet helemaal correct. Sowieso was Longhorn de codenaam voor wat uiteindelijk Vista is geworden en zou dat nooit een productnaam zijn geweest. Tijdens de ontwikkeling van Longhorn hadden de teams evenwel te veel vrijheid en werkte ze niets echt goed af. Zo ontstond een zeer uitgebreid systeem vol met fouten. Op een gegeven moment heeft men dan de reset knop ingeduwd en heeft men de kerndelen die wel goed werkte genomen en is men daarmee opnieuw verder beginnen bouwen onder veel strakker management om tot Vista te komen.

Maar ook Longhorn was geen volledige rewrite natuurlijk. Wat goed is ga je niet weggooien maar hergebruik je gewoon. Ook al omdat je veel toch moet laten zitten wegens de neerwaartse compatibiliteit waarvoor Windows bekend staat.

[mkools24]

Niet helemaal waar, Longhorn stond toch wel los van Vista zeker met die nieuwe UI en zaken als bijv WinFS.

Had die UI Windows 10 maar gehaald trouwens, ziet er zelfs nu nog beter uit dan wat we nu hebben:

https://www.zdnet.com/pic...iting-windows-ui-to-date/

[Verwijderd]

De Longhorn reset was in 2004, de uiteindelijk naam Vista was in 2005 bekend gemaakt. Dus het bleef gewoon het Longhorn project, of het nou die reset had of niet. En alhoewel sommige Aero UIs uit de Longhorn beta's wat anders zijn, bleef Vista toch trouw aan het uiterlijk.

Ben zelf (nostalgisch) fan van de skeuomorfische ontwerpen van het Aero en Apple Aqua tijdperk, maar ik snap ergens wel dat het simpele UI design van tegenwoordig ook wel iets heeft.

[murkienl]

Ik word echt niet warm van die screenshots. Wát een bijelkaar geraapt zooitje. Het is echt een mix/willekeur van Windows XP Mediacenter Edition tot Windows Vista met een MSN Messenger sausje.

Dat ze kunnen beweren dat dat nog steeds de meest "exciting" UI van Windows zou zijn..

(dit allemaal gebaseerd op basis van mijn smaak/mening uiteraard)

[Pendaco]

Dat ze kunnen beweren dat dat nog steeds de meest "exciting" UI van Windows zou zijn..

Artikel komt uit 2012 Maar voor de rest helemaal mee eens. En zelfs voor 2012 was het al vrij gedateerd..

[murkienl]

My bad. Niet goed gekeken naar de publicatiedatum.

[gise]

Heb even die screenshots bekeken op die website maar dat voelt toch echt wel aan als vergane glorie. Design moet wat mij betreft niet afleiden en functioneel zijn, ik zie vooral veel kleuren, designelementen en leuke/lollige icoontjes.

[Tokkes]

Had die UI Windows 10 maar gehaald trouwens, ziet er zelfs nu nog beter uit dan wat we nu hebben:

Wait wut?
Waar we nu lekker strakke lijnen en vlakke UI hebben en het al bij al best prettig werken is, is dit toch veel te druk??

[D-Raven]

Ik ben blij dat dat het dus niet is geworden. Het lijkt wel een kermis attractie. Dat is leuk voor 10 minuten, maar daarna is de lol er al snel vanaf.

[Verwijderd]

Hebben we het over dezelfde screenshots? Wat een nachtmerrie. Windows XP meets MSN Messenger meets <insert random 3D/glossy Rainmeter skin>

Godzijdank dat dat afgeschoten is.

[TonnyTonny]

Server 2003 kernel: Dat is dus dezelfde als XP, servicepack pack 2.

D'r zitten wel meer problemen low-level in Windows die ze nooit er uit hebben gehaald.
Voor een deel denk ik omdat ze als de dood zijn dat het fixen van zo'n bug zoveel onvoorspelbare side-effects heeft dat het middel erger is dan de kwaal.
Je zag dit al jaren geleden toen een groot deel van de Win2000 kernel code-base lekte op het internet. D'r waren stukken code waar de basis funktie in 10-20 regels stond maar die opgeblazen werd tot honderden regels door tientallen workarounds en uitzonderingen om met allerlei randverschijnselen te dealen. Wat is dan precies het effect als je daar iets aan wijzigd?

Na zoveel jaren doorontwikkelen op een bestaande code-base is er waarschijnlijk niemand die volledig begrijpt hoe alles onderling exact samenhangt en waarom in het verleden bepaalde keuzes zijn gemaakt. Dit is eigenlijk vrij normaal bij een dergeliijke grote en complexe code-base.
Dus als het puur iets cosmetisch is en geen security probleem dan blijven ze er liever af.

[jeroen7s]

Vista, dat een snelle fix was na gefaalde Longhorn

Longhorn was gewoon de codenaam voor windows Vista hoor?

[stefanhendriks]

Ik vermoed dat de kernel “van de grond af” gemaakt is. Het ui deel zal dat waarschijnlijk niet zijn.

[CodeCaster]

"Het systeem" omvat zo ontzettend veel meer dan het beetje code dat menu's en vensters op je scherm print.

De veranderingen van Vista naar 7 waren kleiner dan van XP naar Vista.

[rko4u]

Van de grond af opnieuw opbouwen betekent niet altijd dat ook de logica veranderd. Daar is immers geen tijd voor. Mogelijk zijn er zelfs conversietools gebruikt om delen te upgraden naar nieuwe talen en frameworks, maar ik geloof niet dat ze alle code weer opnieuw zouden kunnen ontwerpen en schrijven. Dat zou veel te veel tijd gaan kosten.

[mae-t.net]

Zoals je zelf al aangeeft, kan het simpelweg om een bug gaan die tijdens zijn leven 1 of 2 keer opnieuw is geïmplementeerd. Dat is helemaal niet zo gek als je code schrijft vanuit een functionele specificatie. Het kan natuurlijk ook zijn dat "van de grond af opnieuw opgebouwd" gewoon betekent dat de code uit explorer en internet explorer is gehaald en naar de windowmanager verhuisd, ofzo.

[boe2]

Wat me meer zorgen baart, is dat Microsoft al bij Windows 7 zei dat het systeem van de grond af opnieuw gebouwd zou zijn. Diezelfde belofte kregen we bij Windows 10.

Heb je daar een quote van, want dat lijkt me -heel- onwaarschijnlijk dat Microsoft zoiets belooft. Het lastige aan het Windows besturingsysteem is de hoeveelheid legacy code die het MOET meenemen om compatibiliteit met oude programma's te garanderen.

[YangWenli]

Windows 10 is geen reset geweest- dat is waarom je oude software uit 1998 nog aan de praat krijgt.

[Wouterie]

Dat irriteerde mij ook altijd! Maar ik denk dat ze bedoelen dat ze met oude stenen een nieuw huis hebben gebouwd.

[Han_Solo]

Kan natuurlijk ook aan de onwikkeltools liggen waarmee deze apps gemaakt zijn.

[Marctraider]

Met waarscijnlijk 50% code ge copy paste ;-)

Buiten de kernel om is Windows 10 van binnen een layer over layer, er zitten nog zat componenten van het Windows 2000/XP tijdperk in verborgen.

[Sn0wblind]

Als je een element altijd forceerd op de voorgrond te zijn maakt he tniet uit of he topnieuw geprogrammeerd is of niet. Ze hebben de rule gewoon opnieuw weer beschreven als voorheen.

[latka]

Dat roept MS iedere keer maar het is nog nooit gebeurt. Dat noemen we marketing. De NT kernel is sinds de begindagen intact gebleven en voornamelijk uitgebreid. MS kan het zich ook helemaal niet veroorloven opnieuw te beginnen (lees anders Joel on Software hierover).

[delphium]

Helemaal from scratch opnieuw beginnen zou niet verstandig zijn. Wat Apple heeft gedaan met OSX is natuurlijk wel een optie. *nix als basis is hoe dan ook een verbetering. Zeker als ze die basis netjes open source houden en veel blijven teruggeven aan de community.

[latka]

OSX is een kopie van NextStep (vorig bedrijf van Steve Jobs). Niks nieuws aan, dat gebruikte ik al in 1996 ofzo. Enige wat ze gedaan hebben is MacOS erbij prutsen via emulatie en dat langzaam laten sterven.

[blorf]

Gezien die halve 'quit' wat waarschijnlijk de onderste optie is, waar zit dit menu aan vast?

[Olaf van der Spek]

Het tray icon waar de pointer op rust lijkt mij.

[blorf]

Ik heb het idee dat Pidgin een register-setting ophaalt die de hoogte van het XP-startmenu aangeeft, en mogelijk de inmiddels verdwenen 'actief-venster-flag' daarvan niet meer krijgt en die dus 0 wordt. Het menu krijgt vervolgens dezelfde prioriteit als de niet meer gebruikte startbalk waar het aan vast zit. De oude startbalk ging normaalgesproken standaard naar de voorgrond maar de vervanging is op een andere manier geimplementeerd. De denkbeeldige XP-startbalk bestaat nog steeds in het register maar heeft nu dezelfde settings als elk ander programma.

[Reactie gewijzigd door blorf op 23 juli 2024 07:38]

[Xfade]

Dit zou kunnen inderdaad. Aangezien de enige app die bij mij deze bug heeft, een hele oude utorrent versie is.

[blorf]

Ik denk dat ze die compatibiliteit erin houden om bepaalde oude voor NT ontwikkelde programmatuur niet ineens onbruikbaar te maken.

[SuperDre]

Zou kunnen inclusief mogelijk dus een andere instelling van het schermfont (bv op 150% ipv 100%).

[Stonehawk]

Ik gok dat de linker onder hoek op het aanwijzerpuntje zit.

[Gmount]

Gister zelf ook nog gehad dat de taakbalk bleef staan als ik youtube in fullscreen zette (firefox).
Controls waren nog net aan te klikken dus kon er mee leven.

[batjes]

Waarschijnlijk onderdeel van dezelfde bug. De taakbalk heeft al sinds XP een paar van dit soort bugs waar MS blijkbaar geen goede oplossing voor kan vinden. Ik meen ooit gelezen te hebben dat MS hier wel een oplossing voor had, maar dit weer andere apps sloopt. Maar ik denk ergens dat MS de moet al lang opgegeven heeft en hier weinig aan gaat doen.

Deze bug kom ik ook wel eens tegen, soms minder of niet, soms regelmatig. Een herstart lost dit meestal wel op gelukkig

[Xfade]

Mocht je dit weer gebeuren (gebeurt bij mij soms in games) dan kan je in Taakbeheer de Windows Verkenner opnieuw starten. Dit verhelpt het.

[Terrestrial]

Ja ik ken deze bug inderdaad, over de jaren heen bij diverse Windows versies last van gehad. Is irritant als je een groot uitklap menu hebt.

[HKLM_]

Deze bug zit al eeuwen in Windows en volgens mij is dit nooit anders geweest.

[GieltjE]

Inderdaad, als developer komt deze ondertussen echt m'n nek uit......

[Sannr2]

Is dit niet een issue met de grafische driver die de volgorde niet goed afhandelt? Heb het wel vaker gezien dat een bepaalde driver versie de taakbalk te gretig on top wil zitten. Een nieuwe driver er op of een andere grafische kaart er in en het probleem is weg.

[dasiro]

dat was mijn 2e gedacht, het eerste was de software zelf, aangezien ik verschillende systemtray-icons met minstens 3 verschillende UI context-menu's heb en het bij geen enkele kan reproduceren.

[Rabb]

En soms wil het uitklap menu niet verdwijnen als je er naast klikt. Dan moet je witruimte (of een van die onderscheidings streepjes) in het menu aanklikken zodat die weer de focus krijgt, en daarna kun je er naast klikken en issie weg.

Deze bug kom ik maandelijks tegen.

[telenut]

Is dat wel een bug? Is het niet logisch dat alles achter het startmenu weg gaat? Anders kan je niet meer aan wat op het startmenu staat... of kan het misbruikt worden om het startmenu te 'emuleren'.

[ultimate-tester]

Deze bug treedt op wanneer er een nieuwe foreground window komt terwijl het context menu zich uitklapt en heeft best wel een precieze timing nodig. Een echte edge case dus.
Daarnaast is het ook lastig om te zeggen aan welk team dit moet worden toegekend. Het is geen bug in de kernel, want die doet niks met UI elementen. Misschien is het een bug in Windows, maar misschien komt het enkel voor bij .NET applicaties dus hoort het bij .NET en die gooit het gewoon op foute user implementatie.

Het is best lastig om een window op de foreground te krijgen en je wilt ook niet intrusive een window op de foreground forceren. Windows (of welk systeem dan ook) zal waarschijnlijk 1x het commando sturen om de window richting de voorgrond te sturen maar daarna houdt het op.

Toegegeven, context menus zijn in het algemeen bugged. Hoe vaak ik wel niet een bug heb waardoor een context menu niet wilt verdwijnen als ik ernaast klik (ik moet per se een item uit het menu selecteren). Dat is ook iets uit het Windows 95 tijdperk dat nog steeds voor komt...

[Reactie gewijzigd door ultimate-tester op 23 juli 2024 07:38]