phoenix-76

Members
  • Content count

    31
  • Joined

  • Last visited

Community Reputation

25 Excellent

About phoenix-76

  • Rank
    Freshman
  1. Disable multi-search

    Hello BugSir006, any update on this persisting issue, please? I've just replicated it with the most recent 5.0.4.800 release.
  2. MX 5.0.2.2000 fullscreen problem

    I confirm this issue fixed in 5.0.4.500. Thank you!
  3. Bug: Switching tabs by clicking at the top

    The problem can be actually replicated even in windowed mode when you aim your mouse cursor precisely enough. To me this is yet another manifestation of the 1px MX5 window border issue reported earlier here.
  4. MX 5.0.2.2000 fullscreen problem

    Hello BugSir006, five MX5 releases later the fullscreen issue still persists with 5.0.3.3000. Could you please update us on the progress and fix ETA? My initial understanding was that priority 4 meant the issue would be looked at right after three more urgent problems. I however see that almost 40 different bugs were fixed according to the official change logs since the fullscreen problem was reported. I'm therefore inclined to believe you meant you had assigned the problem with level 4 priority (e.g., 1=Critical, 2=High, 3=Medium, 4=Low) because several people on this forum know how to work around this annoyance. Any chance the priority could be elevated and the bug fixed in some of the upcoming releases?
  5. Disable multi-search

    Hello BugSir006 / 7twenty, Attached is the requested gif. It really does not matter if you perform the first step in the QA page or in the address bar. As long as the search box is not fed with some value at that time, the first search attempt will work OK. I'm glad to inform you that 7twenty finally succeeded to replicate my findings, so hopefully this nasty bug can be quickly fixed. Following is the step-by-step description of the gif content: Notice the maxthon forum page opened on the first tab. Something strange will happen to it later in step 9. Press Ctrl+N to open another tab. Type in the text string you want to look ("London") and press Enter. The text will be looked up using the default search engine (Google in this example). Alt+D to focus the address bar. Type in the search alias string (gmap for Google Maps in this example) and press Space. You can see MX5 immediately launches maps.google.com page with "London" (!!!) as the searched string. Alt+D. Press Backspace to revert the choice of the search engine (this will fall back to default Google search). Alt+D to select the existing URL. Type in another search alias string (map for Mapy.cz in this example) and press Space. You can see MX5 immediately launches mapy.cz page with "London" (!!!) as the searched string. Alt+D. Press Backspace to revert the choice of the search engine (this will fall back to default Google search). Alt+D to select the existing URL. Type in another search alias string (g for Google.cz in this example) and press Space. You can see MX5 immediately launches google.cz page with "London" (!!!) as the searched string. Close the active tab and see what happens. The previously intact maxthon forum page is replaced with google search results of the previously searched string "London". Please note I deliberately used one search string ("London") across all the steps to illustrate the role the broken search box plays in this case. Should you however pick different search string every time, the user experience will get messed up even significantly more.
  6. Disable multi-search

    It seems I narrowed the problem down even more - the problem seems to be linked to 5.0.3.1200 function optimization described as Separate “search box” in the official Change Log. I don't even use the search box feature, so it took me a while to notice that the messed up search alias behavior is somehow linked to this GUI item. Here's the scenario I went through: Alt+D to focus the address bar. Typed "London" and pressed Enter to look it up using the default search engine (Google in my case). I noticed that the Search Box remembered the "London" string and kept it displayed even after the Google search had been completed and its results displayed. (No idea if that's intended behavior or not since I cannot figure out any use case supporting existence of a separate search box these days.) Alt+D. Typed "gmap" to invoke my Google Maps search alias. Pressed "space". At this point the Google Maps page loaded and zoomed to my surprise to... London :-) The test above also explains why the first search attempt using any search alias has always worked for me. The search box cache (or other temporary storage of the searched data) apparently needs to be fed with some value first in order to make the collision with consecutive searches apparent. I would really very much appreciate if this could be looked into by the dev team since all my findings point to a bug in processing logic of the address bar and search box.
  7. Disable multi-search

    Hi 7twenty, I sent you a personal message with a download link. Edit: And to your keyboard management note, I've been using no such software, just two regular OS keyboard localizations - English (US) and Czech (CS).
  8. Disable multi-search

    Hi 7twenty, thanks for all your attempts to replicate the problem. I ran series of additional tests tonight and finally pinpointed first occurence of the problem to 5.0.3.1200! Unless there was some dev version released for internal purposes between 5.0.3.900 and 5.0.3.1200, the latter one is the cause of the problem which destroyed search alias functionality (for me at least). Regarding the test I took, I downgraded my MX5 installation version by version until I found that with 5.0.3.900 (and below) the issue could no longer be replicated. I then upgraded back to the recent version to duplicate the problem and downgraded again to doublecheck 5.0.3.900 fixed the issue for me. The full down/upgrade path of my test: 5.0.3.2000 (issue replicated) -> 5.0.3.1400 (issue replicated) -> 5.0.3.1200 (issue replicated) -> 5.0.3.900 (worked OK) -> 5.0.2.2000 (worked OK) -> 5.0.3.2000 (issue replicated) -> 5.0.3.900 (worked OK) -> 5.0.3.2000 (issue replicated).
  9. Disable multi-search

    What does that imply? That my userdata got somehow messed up with installation of 5.0.3.2000? I take it it's still Maxthon problem, making me the affected side, not the side causing the problem. Btw. I've just replicated the problem scenario on yet another computer with different OS. I will give it a try with the Guest account later. Edit: I've just duplicated the same behavior with Guest account using the predefined Google and Amazon search strings which I only additionally assigned with "g" and "am" aliases. Could using more than one search alias at a time could be the culprit then?
  10. Disable multi-search

    Passport account.
  11. Disable multi-search

    Have duplicated the problem with MX portable right now! Perhaps the only hint I can give on reproducing the problem is to enter the search alias/prefix within the previously used tab - i.e. launch a random page, then re-write the URL in the address bar with custom search alias and see what happens. Repeat several times if necessary, I'm able to reproduce the problem consistently this way.
  12. Disable multi-search

    Despite my Freshman status on this forum I've been using customizable search engine definitions since the ancient My IE2 times (this feature is actually the main reason I've stayed with Maxthon for all these years) and I've registered this problem only with the recent 5.0.3.2000 release, never before as far as I can remember. It was also my first thought to doublecheck whether there were some predefined URL aliases embedded into 5.0.3.2000 that could collide with my own search engine prefixes, but no, there were none. I even temporarily disabled URL alias functionality completely but the issue persisted. To me it's a bug. I would like to highlight that all my custom search engine prefixes work correctly when used within Quick Access search box. The problem can only be reproduced when entering the search prefix into the address bar. As for the procedure of entering the search prefix and the searched value, I of course follow the correct steps: 1. enter the search prefix ("gmap"), 2. press space -> the Google Maps search engine choice gets indicated on the left side of the address bar, 3. enter the searched string (e.g. "London"), 4 press Enter. The problem is that at the moment I press space at step 2, MX5 does not wait for me to enter the "London" string but launches maps.google.com page on its own. At that point the Google Maps search engine indication is still present on the left side of the address bar, however when I finally enter the searched "London" string, it's looked up using my default search engine instead. Following is the Google Maps search string I've been using with the "gmap" prefix which I used for the aforementioned example: https://maps.google.com/maps?q=%us. The problem however impacts my other search engine definitions as well.
  13. Disable multi-search

    Hello, the problem with 5.0.3.2000 search engine management may be somewhat broader than indicated above. I've been using almost 20 custom search engines and all the prefixes I have defined for them (e.g., "gmap" for Google Maps search, "yt" for Youtube search, etc.) work correctly when invoked from the Quick Access page. However when invoking any of the custom search engines from the address bar, the search prefix (e.g. "gmap") is not properly interpreted and instead of waiting for me to input the text I'm looking for (e.g. "London"), the page hosting the search engine (e.g. Google Maps) is launched immediately and the "London" string is looked for using my default search engine (Google) instead.
  14. MX 5.0.2.2000 fullscreen problem

    Hello, can someone please advise why this issue is marked as resolved when it obviously still persists with 5.0.3.2000?
  15. MX 5.0.2.2000 fullscreen problem

    Can somebody else please try to duplicate and confirm this issue to have it officially acknowledged as a bug and to prevent this thread from fading away? I managed to consistently duplicate the problem with white border surrounding fullscreen videos on three machines already, one of which was a completely fresh install. The resolutions tested so far were 2560x1440, 1920x1080, 1200x1600 (portrait mode). I also noticed that the test run by BugSir006 was probably performed in some lower screen resolution, so it might be advisable to preferably verify the problem on full HD and higher resolutions.