okay.. after editing the toolkit autocomplete slightly to restore previously supported near-xpfe behavior i custom-reverted bug 495277 but i used the xpfe impl for fireEvent.. so it supports all three params .. it SEEMS to work .. except for the box that holds current/default search engine in ublist

ubhistory

adjusting which autocomplete urlbar binding calls and of course not conditionally overriding the binding in xul.css

with a little polish OR you figure out how to make it work with the newer initEventHandler shit and autocomplete won

won't need edited

assuming there isn't any other fall out I would likely go forward like this and just remove the search engine box from the ubhistory popup

I have another plan for how to handle search

mainly the current search engine icon in the search button with the context menu being to select which one is the current one

but i'd consider keeping it too if you wanna take my prelem research and make it happen and finally ditch xpfe autocomplete

know the shitty thing? up until like 13.. you could have ditched xpfe autocomplete without much trouble

OKAY.. so there are other bits that need some SLIGHT fixing up as i find them but here is what I have so far..

the other on+handlers should also be method-ized as well.. tho you have one dependancy for the handleURLBarCommand function

I suppose you could just edit sanitize to call gURLBar.handleCommand or something or just not make it a binding method..

sorry sessionHistoryUI.js

OH so do I .. duh

eh that one just leave it where it is.. cba

I dunno if there is anything else to this.. if you want to base your patch on it you will have to figure out a way to get the search stuff to work.. which it doesn't actually seem to on it anyway

how many years.. 2009 is when it should have happened

and it was this easy sans one feature?

IanN_Away: YOU are the designated oldfuck representive of the council why was this never done before?

other than ewong

GrannyGoose: why the fuck did I think changing nsINode wouldn't cause an almost complete rebuild

the Chromeisms Report of the day: Google Docs!

while Palefill restores access, they deployed yet moar Chromeisms™ to break it again... but only barely

"uncaught exception: CustomError: Error in protected function: invalid identity escape in regular expression"

once that one hits, you get a full page overlay blocking everything with a "start page unavailable" message, and a reload button that will reload the page... and the error will happen over and over and over

no big problem, use the inspector to make it go away and use Google Docs normally

but then, found another smaller problem, this time with link sharing

it won't copy links to clipboard, the console logs this error: "document.execCommand('cut'/'copy') was denied because it was not called from inside a short running user-generated event handler"

tomman: polyfills are difficult.. you have to get around csp and other crazy js security that doesn't actually protect people but makes them FEEL like they are protected.. plus polyfills are often written before a spec is finalized and lots of times they don't match chrome's impl which as we know is the ONLY thing that matters even if it is directly contrary to the spec they them selves wrote

this is because (I guess) Google tries to use the navigator.clipboard object (that we do not implement yet), and correctly falls back to document.execCommand

but apparently for that to work on Mozilla you need to declare permissions for it, which Google doesn't do because this codepath was never tested on anything but "old Chrome"

so link sharing is borken in the name of "sekuritah"

even if we did it would have to be fail tollarant because wouldn't the js settings for enabling or disabling clipboard access would apply

so it can't ever LEGIT be a depandant spec

that MUST (rfc must) be done

but that would imply standards matter

So you're telling me Google write the specs and Google violate their own specs?

allow me to non-die of non-shock :D

we're all hippocrits at the end of the day it is just to what degree and how honest we are about it

there is a difference betwene one who is being pragmatic but would take a better option if offered and one who takes glee in it..

"we need to use the latest alpha-spec EctoplasmScript APIs because we believe in progress because otherwise we lose job security and we would age faster!"

anyway i wanna see what frg says about my little exploration into autocomplete and the urlbar binding

at this point the only part of the binding left is the main one extending autocomplete and the hack for paste and go.. i killed the rest .. and xpfe autocomplete

wtf

I go back to the site

try to copy the link again

this time it works!

(I had left the Google Docs tab open with the share dialog open)

glitchy fallback to the old clipboard manip functions?

it's the exact same code

or specifically designed to fail a few times THEN fall back

it failed first because SEKURITAH™, but now works

maybe I should go to the bank and ask for money not in my account - if I ask nicely a few times, I could cause a glitch on their systems and get free money!

what are you registered to vote as?

cause that is the only real determination

tomman: as soon as all the os/2 3.1 and nt4 ATMs age out and get replaced with cloud machines as a service.. you MAY see that happening more

every single ATM in this city runs Windows XP

actually

only a few Diebolds run W7

well still XP was 85% windows 2000 so

i mean windows 10 metro atm apps

sorry 11

also most banks still run XP on their branches too

yeah and that is why the banking system hasn't failed yet

wait until the next generation of apps

a few run 7, one runs 8, and only one I've seen finally moved to 10 because they had to buy new computers for their aggressive expansion

javascript will literally destroy the banking system if the economy doesn't crash first

and even that one that runs W8 uses XP VMs for their (C)RESTRICTED MATERIALS OF IBM (C)1995 IBM CORP backend apps

you realize they are hooking internet connected windows 11 machines up to the nuke early warning system running 60 year old hardware

javascript will kill us all

well emcascript

SPIDERMONKEY WILL SAVE US!

hell, the largest state-owned banks not only still runs XP on ol' IBM Thinkcentres from 2003, they still use Acrobat Reader 4!

IN 2022!

but what version of flash do they use?

cause if it ain't Flash 5...

whatever was the last one running on IE6, I guess

so any activex version

but no problem, every time their backend blows up and we get our money blocked for days, the government here will blame terrorists and the USA

problem solved!

the newest computers they have... are some Wincor Nixdorf ATMs they bought in 2017 :D

but there are so many actually existing things we are at fault for.. why make shit up?

(And even those somehow STILL run XP!)

wait, Diebold and Wincor Nixdorf merged a few years ago

we're doomed

tomman: www-archive.mozilla.org/apology.html

being doomed is only the end not the journey

;)

no, Netscape has been doomed since 1994: jwz.org/gruntle/nscpdorm.html

hello frg_Away

hi

toolkit autocomplete urlbar.

for you it has some additional conserns but .. totally doable for me just enhancement cause the switch is done..

see the backlog

will take a look later. just came home

basically the MAIN thing is to alter the toolkit autocomplete binding to revert bug 495277 and extend fireEvent to accept xpfe's extended capability .. just a few lines really .. that is the only change outside app sources and since it won't impact other consumers since when running with the xpfe binding the behavior was the same anyway also rendering 495277's reasoning moot cause again we are already doing it with the xpfe binding.

Now if you want to retain that Search Engine option in the ac panel you will have to build a more elaborate version than was needed with xpfe ac for me.. I just want the bog standard ac panel with tree view as provided by the binding

cause for me use wise and aestheticly i get a better result than before and less code to maintain

I am sure if you adapt it for yourself it will have some really cool innovation to it that i would have liked to do but don't have the time to get into it right now

well i tried to backport removeChildNode and replaceChildren but for RemoveChildNode all the symbols are conflicting

so it won't link

likely missing some refactor that isolated all the dom comps

or 2015 just won't do it

CaptainTobin does this get rid of the c (++) code for autocomplete?

frg_Away: was that a consern?

i guess if there is any code that isn't used by the toolkit binding it can go but is there any? and would it be wise to make it all js?

frg_Away: you're talking about nsAutoCompleteController?

Yes. Sorry has been a while since I looked.

mozilla doesn't seem to think so xr.binaryoutcast.com/mozilla-centra…rce/toolkit/components/autocomplete

tho they added a jsm

i am sure there may be some specific functions that could be removed or factored down but looks like they are gonna just split it out to each interface add jsm stubs and eventually rewrite it to be jsms or esms

but that is well into the future and past the point either of us will functionally corrupt our code lol

I am actually not opposed to doing as far as splitting the controller apart into its individual interfaces and providing A jsm to instantiate all the interfaces for you as boilerplate

Now I remember. We needed to move the autocomplete in Bug 1418512 but it still has problems in 2.57 because they removed stuff from nsAutocompletController and toolkit bindings. Fx used only the notsoawesomebar and didn't need it.

more proof that their codebase is only for them.

well I have no desire to convert or kill the autocomplete component but i wouldn't consider any of it to really be xpfe .. i think that was factored and refactored ages ago .. the main thing was the binding cause they wanted to .. well drop features so yeah history repeats its self cause no one learned from it. I want all the features but I don't want seperate implimentations to get it. My final autocomplete binding eventually won't be toolkit or

xpfe but .. runtime!

but yeah i think it isn't overly screwy component to have around as-is

btw another reason i am not conserned with preserving the search engine option in the urlbar ac panel is because I plan to replace the searchbox and the search button with a new search button that will reflect the current engine's favicon and the context menu will be how to select which engine and just use the address bar as the search textbox input .. slightly different approch to the various ones abound..

The awesomebar is crap but I wouldn't mind a single urlbar implementation with a proper drop down marker. Something every current browser misses. Would be cool to have the dropdown marker wich you could configure to show only typed urls or all recent if you want and a single implementation. I use a seperate search bar but other might still want it in the url bar. I can do without and...

...especially with "helpful" search suggestions from the web.

I didn't consider search suggestions

how does this sound.. Search Button.. Split menu button normal action search current engine, dropdown selecting one of these will search with it instead.. set current in preferences.. let add-on developers work out search suggestions or adding the full search box back

I would even just need something simpler like getting rid of urlbarhistory.sqlite and use searchfox.org/mozilla-esr60/source/…rowser/base/content/browser.js#4259 aka PlacesUIUtils.markPageAsTyped(aUrlToAdd). Then one styling for typed content and the dropdown. Maybe a ctrl-click and/or pref to choose default behaviour of the dropdown.

If you know what I mean.

you want it to be places driven complete

like firefox

without the crap :)

well then restore nsHistory and nsBookmarks

OH

ok lol

The information is already in places and I think it would reduce complexity.

i just wish they had retrofitted different storage backends to the same interfaces instead of re-inventing the wheel

frg_Away: maybe

wouldn't just setting it to unifiedcomplete do that instead of history file

I don't want to become more dependant on places cause I may one day replace it

but yeah man

halfway but then you still need to find a way to show only typed urls. If you just want to showe recent ones would be easier. But unified complete would need to be cleaned up. Stuff like what to show first based on made up numbers how many time the user blinked and so on is just urgkkk....

the problem with the places framework is it assumes most everything will be browser-based

so you would have a need for an all encompasing bookmarks history session etc system in theory

besides, one advantage is you can access urlbar history anywhere without a bunch of grief with any autocomplete textbox

of staying with the seperate storage\

well lets just say there are some valid bugs open against it wrt clearing and/or what is stored. In need for an overhaul aynway.

can't argue with you there

the urlbar at the time was rebased on the latest code at the time plus mods

during the transition

but the transition happened in the 1.5-2.0 era so some .. a lot is still very much in that state .. which is fine for most things but for bindings like search urlbar and tabbed browsing it is pretty noticable functionality wise

wait a minute

if the autocomplete source is nsPlacesAutoComplete and i am not using the populated menupopup anymore.. am i even using the fuckin ub history sqlite db?

well piss

i completely miscalculated

yeah ok.. i fucke dup.. i need to re-add ubhistory for the dropdown

why aren't icons shwoing up in the menupopup form

well you see where are some of the things I think should be changed are coming from :)

well the behavior is consistant with Pale Moon but it isn't what i want.. I want typed urls not recent history.

now past Pale Moon it might be different

but obviously that was enough for firefox

at one time

unless i botched that years ago and literally no one noticed since

i would think urlbar behavior changes would have been noticed and bitched about

a little more important than a 1px gap

ok.. frg_Away the results i am getting back JUST with the dropmarker seem to be SUCCESSFULLY completed navigation OF typed urls only but seems to be in reverse order?

old to new?

i dunno

no i think it is just history from old to new

hmm

how do i get an alt source for the dropmarker

that should be theoretically not difficult..

if i override the binding on the urlbar history dropmarker and just TELL it to do something else.. then yeah

hello tonymec|away

CaptainTobin: hello

frg_Away: did firefox just never do this after it switched to places?

until much later

I think they ditched it at first chance.

but there is no places eq

so what i have to EITHER live with urline and history as the sources.. OR unifiedcomplete or i am gonna have to write my own autocomplete wrapper or fuck over some sort of custom popup

while the xpfe binding simple.. worked..

maybe toolkit autocomplete is bullshit

and maybe xpfe autocomplete is superior and just needs enhanced

frg_Away: well that is ONE way personal.mattatobin.com/image/captu…b74-6d8f-40b8-ba2f-5bea26d1a84e.jpg but hmm

why wouldn't mozilla have a default popup value of some sort

for occasions like this

I guess all I really need to do is rewrite the function that populates a panel with a tree and apply autocomplete styling and make it show up where it is supposed to

Can I have a superawesombar with the best of both worlds. Duck.... :)

the Pale Moon one is fucked

it is using an earier binding

mainly because it still used richlistview

and the SeaMonkey one all over the place as discussed.

we been using fuckin treeviews

well I will sleep well over it now. nn

as near as I can tell the default resultset no matter if you are including urline or not is by frequency of visits

i suppose urlite means frequency of visits of typed urls