13 minutes ago, TimG said:

Problem is, for the moment at least, we can’t find a problem and, so far, no-one else has reported this as an issue. Rich has been checking various logs and nothing has turned up so far

The problem is not obligatory visible in the logs, server side.

If some problems are on the client side you will never see anything.

What I (copilot) found is that some script crashed client side, as consequence the upload is disactivated.


The problem is NOT firewall or such things... I try from 2 PCs booth on the last version of Win11, and Edge...

No change if I go over different connections... also from an other country (not over a VPN but really in an other country)

For your information I'm working in the IT world ( a worked in different branches, and have a little bit know-how in firewall / PC's and as developer )

24 minutes ago, CaolIla said:

The problem is not obligatory visible in the logs, server side.

If some problems are on the client side you will never see anything.

What I (copilot) found is that some script crashed client side, as consequence the upload is disactivated.


The problem is NOT firewall or such things... I try from 2 PCs booth on the last version of Win11, and Edge...

No change if I go over different connections... also from an other country (not over a VPN but really in an other country)

For your information I'm working in the IT world ( a worked in different branches, and have a little bit know-how in firewall / PC's and as developer )

Hi Caolla,

I completely understand your frustration, and I want to assure you that we are not ignoring the issue.

As Tim mentioned, we are currently stuck trying to reproduce it. On our end, everything appears normal, and our tests on Windows 11 using Edge did not show any problems. I also ran tests today across two different computers and accounts, and everything worked as expected.

To get to the bottom of this, we have opened a support ticket with Invision and are currently waiting for their feedback.

Please bear with us. Our platform is a free community project that we maintain in our spare time from different parts of the world, and we are doing our best to help. We will update you as soon as we hear back.

Ciao

No frustration is not the good word.

I gave you all the information I have / found and the problem is that you ignore / exclude that the problem can be on your side.

But it's ok (may be not)

Bye

Thanks — your latest tests are actually very useful, because they narrow the problem down a lot.

    

    From what you’ve shown, this is not a simple upload permission or quota issue. Your account can upload images, and the server does accept them. We can see that uploads work when you create a new topic/private message, and your screenshot also shows that uploads work when you edit a message after posting it.

    

    The pattern now looks much more specific:

    

    - New topic/new message editor: works

    - Edit existing post/message: works

    - Initial reply editor: fails for you

    - Replying to a private message: also fails for you

    - Windows 11/Edge works for some of us, but not on your affected machines

    

    So the issue appears to be with the initial reply editor/quick-reply editor not fully initializing the attachment/paste component on your setup. That is a much narrower and more useful diagnosis than “uploads are blocked.”

    

    I also want to be careful about the Copilot explanation. It may be pointing in the right direction, but we need the actual browser console error from your machine rather than only Copilot’s interpretation of what it can see client side, From our side we cannot currently reproduce the failure, No other members in the same group are saying they have the same problem and the page does not show the same error for us who have tested it.

    

    The best next step is:

    1. Open the affected reply page.

    2. Press F12.

    3. Go to Console.

    4. Clear the console.

    5. Click into the reply box.

    6. Try to paste an image.

    7. Screenshot any red errors exactly as they appear.

    

    If possible, please also do the same test in an Edge InPrivate window with extensions disabled. Not because we are blaming your setup, but because we need to know whether the failing reply editor is caused by cached/script state, an extension/security layer, or an Invision editor bug.

16 minutes ago, RichN said:

  If possible, please also do the same test in an Edge InPrivate window with extensions disabled. Not because we are blaming your setup, but because we need to know whether the failing reply editor is caused by cached/script state, an extension/security layer, or an Invision editor bug.

Same reaction it doesn't work

It's late I need to go to bed now. Wakup in 5 hour to go to work.

I paste the console output to Copilot... (I know copilot is copilot ;) ) the result is what I gave you.

Thanks. The Copilot summary is useful as a clue, but we need the raw browser console output, not Copilot’s interpretation of it.

    

    The reason is that Copilot may be summarizing, guessing, or connecting errors that are not actually the cause. To investigate this properly — and especially if we need to send it to Invision — we need the exact original error text, file name, and line number shown by Edge.

    

    When you have time tomorrow, please do this:

    

    1. Open the page where reply upload/paste fails.

    2. Press F12.

    3. Go to the Console tab.

    4. Clear the console.

    5. Click into the reply editor.

    6. Try to paste/upload an image.

    7. Copy/paste the actual red console errors here, or send a screenshot.

    

    What we know so far is useful:

    

    - New topics/new messages work.

    - Editing an existing post/message works.

    - The initial reply composer fails on your affected machines.

    

    That points us toward the reply editor initialization, but we need the raw console error to confirm where it is failing.

When I click in this box after 10 or 15 sec
this message

main-mfr2DxeI.js?v=4c29a2ba741785983349:130 [Violation] 'setTimeout' handler took 71ms

[Violation] Forced reflow while executing JavaScript took 57ms

[NEW] Explain Console errors by using Copilot in Edge: click to explain an error. Learn moreDon't show again

root_front.js?v=4c29a2ba741785983349:258 Uncaught (in promise) TypeError: Cannot convert undefined or null to object

at Object.assign (<anonymous>)

at BaseControllerClone._updateTimestamp (root_front.js?v=4c29a2ba741785983349:258:449)

at BaseControllerClone._doAjaxRequest (root_front.js?v=4c29a2ba741785983349:250:6)

at BaseControllerClone._checkNotifications (root_front.js?v=4c29a2ba741785983349:249:6)

updateTimestamp @ rootfront.js?v=4c29a2ba741785983349:258

doAjaxRequest @ rootfront.js?v=4c29a2ba741785983349:250

checkNotifications @ rootfront.js?v=4c29a2ba741785983349:249

setInterval

setInterval @ rootfront.js?v=4c29a2ba741785983349:240

setup @ root_front.js?v=4c29a2ba741785983349:236

initialize @ root_front.js?v=4c29a2ba741785983349:233

initControllerOnElem @ root_framework.js?v=4c29a2ba741785983349:156

initializeControllers @ root_framework.js?v=4c29a2ba741785983349:126

init @ root_framework.js?v=4c29a2ba741785983349:122

(anonymous) @ root_library.js?v=4c29a2ba741785983349:70

e @ root_library.js?v=4c29a2ba741785983349:2

t @ root_library.js?v=4c29a2ba741785983349:2

setTimeout

(anonymous) @ root_library.js?v=4c29a2ba741785983349:2

c @ root_library.js?v=4c29a2ba741785983349:2

fireWith @ root_library.js?v=4c29a2ba741785983349:2

fire @ root_library.js?v=4c29a2ba741785983349:2

c @ root_library.js?v=4c29a2ba741785983349:2

fireWith @ root_library.js?v=4c29a2ba741785983349:2

ready @ root_library.js?v=4c29a2ba741785983349:2

P @ root_library.js?v=4c29a2ba741785983349:2

Good night... Need to go

[Violation] Forced reflow while executing JavaScript took 93ms

[Violation] Forced reflow while executing JavaScript took 83ms

root_front.js?v=4c29a2ba741785983349:258 Uncaught (in promise) TypeError: Cannot convert undefined or null to object

at Object.assign (<anonymous>)

at BaseControllerClone._updateTimestamp (root_front.js?v=4c29a2ba741785983349:258:449)

at BaseControllerClone._doAjaxRequest (root_front.js?v=4c29a2ba741785983349:250:6)

at BaseControllerClone._checkNotifications (root_front.js?v=4c29a2ba741785983349:249:6)

updateTimestamp @ rootfront.js?v=4c29a2ba741785983349:258

doAjaxRequest @ rootfront.js?v=4c29a2ba741785983349:250

checkNotifications @ rootfront.js?v=4c29a2ba741785983349:249

setInterval

setInterval @ rootfront.js?v=4c29a2ba741785983349:240

setup @ root_front.js?v=4c29a2ba741785983349:236

initialize @ root_front.js?v=4c29a2ba741785983349:233

initControllerOnElem @ root_framework.js?v=4c29a2ba741785983349:156

initializeControllers @ root_framework.js?v=4c29a2ba741785983349:126

init @ root_framework.js?v=4c29a2ba741785983349:122

(anonymous) @ root_library.js?v=4c29a2ba741785983349:70

e @ root_library.js?v=4c29a2ba741785983349:2

t @ root_library.js?v=4c29a2ba741785983349:2

setTimeout

(anonymous) @ root_library.js?v=4c29a2ba741785983349:2

c @ root_library.js?v=4c29a2ba741785983349:2

fireWith @ root_library.js?v=4c29a2ba741785983349:2

fire @ root_library.js?v=4c29a2ba741785983349:2

c @ root_library.js?v=4c29a2ba741785983349:2

fireWith @ root_library.js?v=4c29a2ba741785983349:2

ready @ root_library.js?v=4c29a2ba741785983349:2

P @ root_library.js?v=4c29a2ba741785983349:2

thanks.. good night ill research more..

1 hour ago, CaolIla said:

No frustration is not the good word.

I gave you all the information I have / found and the problem is that you ignore / exclude that the problem can be on your side.

But it's ok (may be not)

Bye

I wanted to reply directly to this also, I am sorry it came across like I, or we, were dismissing the problem or putting it on you. That was not the intent.

The reason I kept asking for the raw console errors is that I need them to debug this properly, and also to give Invision something specific if we need to submit it to them. A Copilot summary can be useful, but it is not enough on its own. Invision will need the actual error text, file name, line/function, browser, and the exact steps that trigger it.

The error you sent is helpful because it gives us something real to trace. That said, the error appears to be coming from Invision's notification/checking script, not directly from the image uploader itself. So it may be related, or it may just be another JavaScript error happening on the same page. I do not want to claim either way until we know more.

So I am not ignoring the issue, and I am not ruling out that something on the site is involved. I am also not ruling out that something local to your browser/profile could still be blocking part of the reply editor, since the same page is working for others. That could be cached site data, browser storage, an extension, a privacy/security setting, or something specific to that Edge profile. It is also possible that something is cached somewhere between the server and you.  

I am trying to separate what we know from what we do not know, so we can either fix it here or give Invision a proper report.

I appreciate you sending the extra details. I know this has been aggravating, but the console output does help.

Also, please remember that we all volunteer to run this site for free for you all. Time zones make things harder, and as the more technical admin I am fitting this around my normal work schedule, which is often 60 hours a week. Your patience is appreciated.

It is being worked on, even if it cannot always move as quickly as either of us would like.

I am not an IT person or anything, but I am trying to figure out why you are insisting on "cut and paste" instead of "drag and drop"? I always drag and drop any photos or videos and have no problems at all (unless they are too large).

3 hours ago, SwiftFF5 said:

I am not an IT person or anything, but I am trying to figure out why you are insisting on "cut and paste" instead of "drag and drop"? I always drag and drop any photos or videos and have no problems at all (unless they are too large).

Cut&Paste + Drag&drop it doesn't work.. it's the same probleme. If the banner appear I can paste if it's not I Ican't paste.

Why I use Paste : Easy, I use Greenshot and when I select a region I configure Greeshot to put it in the clipboard... It's fast and that's a important point for me.

@RichN I know you are and other volonteer I appreciate the work you all have done That's not the problem ;)

On the other side all the member writing reviews, share some DIY etc... are also volonteer we participate to the life of the site, putting some intersting stuff on it.

It's like for you time we "invest" to make the site living

Thanks for try to solve "my" problem.

I have now captured the failure on your account twice, automatically, without you needing DevTools. Once on this topic at 17:04, and once in a private message at 19:39. Same result both times.

Invision does have a client-side debug path, but it is switched off in the version they ship. When the attachment area fails to appear, the software calls Debug.error() — and in production that call goes nowhere. Debug starts disabled, nothing ever turns it on, and no adapter is registered to write those messages anywhere. The failure never reaches the server logs, which is why there was nothing useful to look at on our side.

So I added a small diagnostic of our own. It watches the reply box expand, records whether the attachment request happened, what came back, and whether the "Drag files here..." bar actually appeared in the page. That is how we caught your two failures today. It does not collect the text of unsent messages — only whether the attachment UI loaded.

The request that fetches the attachment area does reach the server, and the server answers 200 OK with a full response. The upload library also loads. After that, the bar never appears in the page. It isn't hidden, and it isn't being removed by an extension — it simply never gets inserted.

New topics, post edits, and any reply box that already has text in it ship the attachment area with the page. A blank reply box (forum or messenger) fetches it afterwards. Only that second path is failing for you.

Your account is not the problem. Two other members on Windows 11 with Chromium 151 also work. Zoom, High Contrast, and storage are all fine on the sessions we captured.

Object.assign ERROR

You were right to flag that, and the analysis you posted got the structure genuinely right — new topics load the editor in full, replies fetch part of it separately. That matches the source code exactly.

The error itself turned out to be a dead end. I get that identical "Cannot convert undefined or null to object" message on my own machine, in a session where uploading works perfectly. It is a harmless ordering bug in the notification code, unrelated to attachments. Real, and worth chasing, and I did chase it. It just didn't lead anywhere.

Could you try once more, on this topic, the same way it usually fails — click into the empty reply box and wait a few seconds. If the attachment area still doesn't appear, you don't need to paste anything from DevTools. A short "still missing" here is enough; we will already have the diagnostic.

If you have a moment, a second try in a private message (empty reply box again) would be useful too. That is the other place we saw it fail.

thanks...

I waited 20 seconds ?... nothing appear

An idea... I'm using a PC with the language set to French... just as info...

If I have time I'll switch to English and show if something change ( I had in my work life some trouble with Swiss-German language setup together with Time I need to be sure that the reason of the problem is not a "setup" problem... that is not handle in the good way.

Sorry but my PC is configure as Swiss-French it is certainly a test to do to change it to English

Thanks — that 20-second wait matches what we captured. The request for the attachment bar succeeded and the HTML was in the response; it just never got added to the page on your machine.

Your Swiss-French Windows idea is a good test. The forum account is already set to English; what’s different is the browser reporting language Fr. If you get a chance to switch the PC (or just Edge) to English and click the empty reply box once, that would tell us whether locale is involved. No rush, and you don’t need DevTool

I can see the request succeeding and the HTML arriving. The next bit is in how the browser adds that HTML to the page, and I’ve put a small fix in for that.

Could you refresh the topic (Cmd/Ctrl-Shift-R) and click the empty reply box once more? If “Drag files here…” shows up, we’re done. The French Windows test can wait.

You see

I made a screenshot and with paste....

It works.... in consequence It was not the local Swiss-French setup of my PC (or perhaps but your change solve the problem)

An other test to be sure that it's ok

Now for me it's time to leave..... it's diving day :)

Enjoy!!!!

Ok great.... The attach bar is fetched when you click a blank reply, then inserted. That insert has a bug. For almost everyone it still works.

Your browser session was the only one we saw that got an extra script in that fetch, so the bug skipped the “Drag files here…” block.

Something on your side is making the software send that extra script. The best fit is your browser language set to French while the account is English, or an extension / VPN changing headers or cookies.

The work around I put on the site seems to be workin.... I have reported the bug to Invision.

If a blank reply ever loses the attach area again, tell me.

Thanks all who helped or "only" try to help... ;)

If I found time tomorow I'll make a new topic with what I wanted to make at the begining.

Good night, morning evening afternoon depending of your location..

Hugues