frg_Away: What was blocking using toolkit autocomplete in seamonkey anyway?

aside from mailnews ui

I know the urlbar uses it

did you ever eventually switch it over

NewTobinParadigm Before my time but I think yes mostly urlbar / unifiedcomplete junk. Didn't switch for urlbar but form autocomplete uses it if I am not mistaken. .

afaik content autocomplete uses toolkit as does unifiedcomplete when in that mode but the urlbar seems to be PART xpfe autocomplete part toolkit autocomplete it is very strange

yes If you use the dropmarker it uses xpfe. If you enter data indeed autocomplete but I think own "hybrid" implementation. Has been some time since I looked.

so dropdown content is being fed from urlbarhistory.sqlite

i remember now

hmm

Comes with its own can of worms. paswords saving...

looks like if one wants to get rid of the xpfe autocomplete one might have to delve into the older per-tab/browser session history

involving the back forward urlbar dropdown and the Go menu

switch that all over to places

not sure it is worth the work for me least at this time

I personally never liked places as a component

i much prefered the orginal bookmark and history components

those could have been modified to use sqlite

but this unified bookmarkshistoryeverythingelsecrap and its UI always rubbed me the wrong way

of course if one wanted to re-invent something more akin to the orginal services u'd have to also take favicons into account as well

I like the history and bookmarks integration. I dislike the download integration. One of the reasons I didn't port this part but it seem alien to me there.

And trips over itself when it encounters a non common scheme like for imap mail attachments.

JSDownloads sucks because it never gained the full rich functionality of str8 nsDownloads and its association with places is ponderous and of course .. you MUST impliment your own everything for it.. it is very Modern Firefox thinking

no regard for the platform nature of the shared code

also for me.. files transfer faster than with JSDownloads and I never could figure out why

especially when one of the touted features at the time was that JSDownloads download faster

I am gonna merge the toolkit ui service with the suite downloads ui service and make EITHER xul window avilable

and i am gonna kick JSDownloads out of the tree

it can live in homerchu.. I'll leave the nsDownloads stubbing in place but remove the pref

tho i may not even bother with the Aviary design one

the communicator UI is superior after all

also frg_Away I am indeed going to take in your mod for the toolbar grippies and set that as default off.. I like that but I never use them and having them on just highlights them NOT being there in Interlink

Either.. all toolbars get grippy capable globally or eventually I will just not have grippys at all

even though I love them so

I constantly "misclicked" and did hide the tool- or menubar. I wasn't alone.

well then maybe it is time to consider just ditching the xpfe toolbar emulation bindings

as sad as that might be..

frg_Away: think any of this would apply to 56? code.binaryoutcast.com/projects/aur…5d1208df649f666adb73a9f74584105113c

his patch would better apply to the mozstructure

but yeah

I am guessing if Mozilla's behavior ever became correct it did so by replacement not actual fixing

Exported it into my patches directory. Form fill /autocomplete has been changed and changed and changed between 52 and 56 so not sure.

yeah, That is why I am not looking to patch any of the discreet components unless they can be made better or to fix issues

and why I left dom, js, and layout where they were as hotpaths of stuff that DO have to be patched if any advancement is to be done

crap like autocomplete or downloads or whatever would have to be adapted anyway for such patches what is one more step with the restructure and standardization of that structure

and as far as ARE is conserned.. the same principle for leaving hard to track hot paths for patching applies just the same

status meeting notes are done (late):

oh wow, Pontoon stopped working with SeaMonkey!?

yeah, I think so

the logon page (Mozilla account) indeed gets stuck on an infinite spinner

(no errors logged to console)

IIRC you needed a UA override for accounts.firefox.com, but that doesn't seem to work anymore

at one point, I think you needed to indicate Fx56, as otherwise it'd try to use features that are/were not present

but I think now the actual pontoon interface also requires something more